mime-types-data 3.2016.0521 → 3.2022.0105

checksums.yaml

@@ -1,7 +1,7 @@
 ---
-SHA1:
-  metadata.gz: 2747f196c42646e5aa4da822e481bebcb1f0b26b
-  data.tar.gz: bdefbe341f03cf250667ac0f19ffe6cf157efc9a
+SHA256:
+  metadata.gz: 329d601098ccd4e2d3978e6e323230a2ae19d2349f869711d899207c19b16994
+  data.tar.gz: 1dedab8c410c72bb0c84cb089000b87003a026ac109b9bf7cac165b102720fac
 SHA512:
-  metadata.gz: 9bac329c65e88677c29b472495b7b4a2340aea5dd002894e1817ddf7c33867f493875407ac66c2e8885dad3b98c8fcb4bb16d07341c3cedcbe4cb68b71677ab3
-  data.tar.gz: 92754f80d611368684b2bb721e5e0bb1515b6db29bf612662b3eb57e5d134a4f0fa12ba142bc00d20b8dbb3665738f8068a3e90be11e7952ddfd85d3c999f553
+  metadata.gz: 1c2c164f48716aebc3caed14a571f783aea3397cb218b6bc494c960561304a593a8e13c7f6362e1d9abd900c3c6b7752fa2cc8bdae6fb41681178fa3186dddbe
+  data.tar.gz: 3272473043d3359581c716e0fff76225219302573f7a1c31c7755b6fce7a4ad40aa0f183889e55f61fb043133562ba2e682b214cb2843df5340bc5ad50b3b8a3

data/Code-of-Conduct.md

@@ -4,31 +4,31 @@
 
 In the interest of fostering an open and welcoming environment, we as
 contributors and maintainers pledge to making participation in our project and
-our community a harassment-free experience for everyone, regardless of age,
-body size, disability, ethnicity, gender identity and expression, level of
-experience, nationality, personal appearance, race, religion, or sexual
-identity and orientation.
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of
+experience, nationality, personal appearance, race, religion, or sexual identity
+and orientation.
 
 ## Our Standards
 
 Examples of behavior that contributes to creating a positive environment
 include:
 
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
 
 Examples of unacceptable behavior by participants include:
 
-* The use of sexualized language or imagery and unwelcome sexual attention or
+- The use of sexualized language or imagery and unwelcome sexual attention or
   advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic
   address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
+- Other conduct which could reasonably be considered inappropriate in a
   professional setting
 
 ## Our Responsibilities
@@ -37,20 +37,20 @@ Project maintainers are responsible for clarifying the standards of acceptable
 behavior and are expected to take appropriate and fair corrective action in
 response to any instances of unacceptable behavior.
 
-Project maintainers have the right and responsibility to remove, edit, or
-reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
-threatening, offensive, or harmful.
+Project maintainers have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, or to ban temporarily or permanently any
+contributor for other behaviors that they deem inappropriate, threatening,
+offensive, or harmful.
 
 ## Scope
 
 This Code of Conduct applies both within project spaces and in public spaces
 when an individual is representing the project or its community. Examples of
 representing a project or community include using an official project e-mail
-address, posting via an official social media account, or acting as an
-appointed representative at an online or offline event. Representation of a
-project may be further defined and clarified by project maintainers.
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
 
 ## Enforcement
 

data/Contributing.md

@@ -1,22 +1,22 @@
 ## Contributing
 
 Contributions to mime-types-data is encouraged in any form: a bug report, new
-MIME type defintions, or additional code to help manage the MIME types. As with
+MIME type definitions, or additional code to help manage the MIME types. As with
 many of my projects, I have a few suggestions for improving the chance of
 acceptance of your code contributions:
 
-* The support files are written in Ruby and should remain in the coding style
+- The support files are written in Ruby and should remain in the coding style
   that already exists, and I use hoe for releasing the mime-types-data RubyGem.
-* Use a thoughtfully-named topic branch that contains your change. Rebase your
+- Use a thoughtfully-named topic branch that contains your change. Rebase your
   commits into logical chunks as necessary.
-* Use [quality commit messages][qcm].
-* Do not change the version number; when your patch is accepted and a release
+- Use [quality commit messages][qcm].
+- Do not change the version number; when your patch is accepted and a release
   is made, the version will be updated at that point.
-* Submit a GitHub pull request with your changes.
-* New or changed behaviours require new or updated documentation.
+- Submit a GitHub pull request with your changes.
+- New or changed behaviours require new or updated documentation.
 
 Although mime-types-data was extracted from the [Ruby mime-types][rmt] gem and
-the support files are written in Ruby, the *target* of mime-types-data is any
+the support files are written in Ruby, the _target_ of mime-types-data is any
 implementation that wishes to use the data as a MIME types registry, so I am
 particularly interested in tools that will create a mime-types-data package for
 other languages.
@@ -26,35 +26,35 @@ other languages.
 The Ruby mime-types gem loads its data from files encoded in the `data`
 directory in this gem by loading `mime-types-data` and reading
 MIME::Types::Data::PATH. These files are compiled files from the collection of
-data in the `types` directory. Pull requests that include changes to these
-files will require amendment to revert these files.
+data in the `types` directory. Pull requests that include changes to these files
+will require amendment to revert these files.
 
 New or modified MIME types should be edited in the appropriate YAML file under
-`types`. The format is as shown below for the `application/xml` MIME type
-in `types/application.yml`.
+`types`. The format is as shown below for the `application/xml` MIME type in
+`types/application.yml`.
 
 ```yaml
-  - !ruby/object:MIME::Type
-    content-type: application/xml
-    encoding: 8bit
-    extensions:
+- !ruby/object:MIME::Type
+  content-type: application/xml
+  encoding: 8bit
+  extensions:
     - xml
     - xsl
-    references:
+  references:
     - IANA
     - RFC3023
-    xrefs: !ruby/hash:MIME::Types::Container
-      rfc:
+  xrefs:
+    rfc:
       - rfc3023
-    registered: true
+  registered: true
 ```
 
 There are other fields that can be added, matching the fields discussed in the
 documentation for MIME::Type. Pull requests for MIME types should just contain
-the changes to the YAML files for the new or modified MIME types; I will
-convert the YAML files to JSON prior to a new release. I would rather not have
-to verify that the JSON matches the YAML changes, which is why it is not
-necessary to convert for the pull request.
+the changes to the YAML files for the new or modified MIME types; I will convert
+the YAML files to JSON prior to a new release. I would rather not have to verify
+that the JSON matches the YAML changes, which is why it is not necessary to
+convert for the pull request.
 
 If you are making a change for a private fork, use `rake convert:yaml:json` to
 convert the YAML to JSON, or `rake convert:yaml:columnar` to convert it to the
@@ -65,8 +65,25 @@ new columnar format.
 If you are maintaining a private fork and wish to update your copy of the MIME
 types registry used by this gem, you can do this with the rake tasks:
 
-    $ rake mime:iana
-    $ rake mime:apache
+```sh
+$ rake mime:iana
+$ rake mime:apache
+```
+
+##### A Note on Provisional Types
+
+The file `types/provisional-standard-types.yaml` contains the provisionally
+registered types from IANA. Per IANA,
+
+> This registry, unlike some other provisional IANA registries, is only for
+> temporary use. Entries in this registry are either finalized and moved to the
+> main media types registry or are abandoned and deleted. Entries in this
+> registry are suitable for use for development and test purposes only.
+
+The provisional types file is rewritten when updated, so pull requests to
+manually promote or customize provisional types (such as with extensions). It is
+recommended that any updates required to the data be performed in your
+application if you require provisional types.
 
 ### Development Dependencies
 
@@ -74,12 +91,16 @@ mime-types-data uses Ryan Davis’s {Hoe}[https://github.com/seattlerb/hoe] to
 manage the release process, and it adds a number of rake tasks. You will mostly
 be interested in:
 
-    $ rake
+```sh
+$ rake
+```
 
 which runs the tests the same way that:
 
-    $ rake test
-    $ rake travis
+```sh
+$ rake test
+$ rake travis
+```
 
 will do.
 
@@ -87,71 +108,134 @@ To assist with the installation of the development dependencies for
 mime-types-data, I have provided the simplest possible Gemfile pointing to the
 (generated) `mime-types-data.gemspec` file. This will permit you to do:
 
-    $ bundle install
+```sh
+$ bundle install
+```
 
 to get the development dependencies. If you aleady have `hoe` installed, you
 can accomplish the same thing with:
 
-    $ rake newb
+```sh
+$ rake newb
+```
 
 This task will install any missing dependencies, run the tests/specs, and
 generate the RDoc.
 
 You can run tests with code coverage analysis by running:
 
-    $ rake test:coverage
+```sh
+$ rake test:coverage
+```
 
 ### Workflow
 
 Here's the most direct way to get your work merged into the project:
 
-* Fork the project.
-* Clone down your fork (`git clone
-  git://github.com/<username>/mime-types-data.git`).
-* Create a topic branch to contain your change (`git checkout -b
-  my\_awesome\_feature`).
-* Hack away, add tests. Not necessarily in that order.
-* Make sure everything still passes by running `rake`.
-* If necessary, rebase your commits into logical chunks, without errors.
-* Push the branch up (`git push origin my\_awesome\_feature`).
-* Create a pull request against mime-types/mime-types-data and describe what
+- Fork the project.
+- Clone down your fork (`git clone git://github.com/<username>/mime-types-data.git`).
+- Create a topic branch to contain your change (`git checkout -b my\_awesome\_feature`).
+- Hack away, add tests. Not necessarily in that order.
+- Make sure everything still passes by running `rake`.
+- If necessary, rebase your commits into logical chunks, without errors.
+- Push the branch up (`git push origin my\_awesome\_feature`).
+- Create a pull request against mime-types/mime-types-data and describe what
   your change does and the why you think it should be merged.
 
+### The Release Process
+
+The release process needs automation; as it includes generating code and
+committing to the repository, it is not clear how this will happen safely.
+
+1. Review any outstanding issues or pull requests to see if anything needs to be
+   addressed. This is necessary because there is currently no automated source
+   for extensions for the thousands of MIME entries. (Suggestions and/or pull
+   requests for same would be deeply appreciated.)
+2. `bundle install`
+3. `bundle exec rake mime:apache`
+4. `bundle exec rake mime:iana`
+5. Review the changes to make sure that the changes are sane. The IANA data
+   source changes from time to time, resulting in big changes or even a broken
+   step 4. (The most recent change was the addition of the font/\* top-level
+   category.)
+6. `bundle exec rake convert`
+7. `bundle exec rake update:version`
+8. Write up the changes in History.md. If any PRs have been merged, these should
+   be noted specifically.
+9. Commit the changes and push to GitHub.
+10. `bundle exec rake release VERSION=newversion`
+
+### Automating the Release
+
+If anyone wishes to provide suggestions on automation, this would be a two-phase
+process:
+
+1. A system would need to periodically create PRs to the GitHub repository with
+   the output of the following commands (steps 2, 3, and 4):
+
+   ```sh
+   bundle install
+   bundle exec rake mime:apache
+   bundle exec rake mime:iana
+   git add .
+   git commit -m "[Automated] MIME Type update for $(date)"
+   # Somehow make the PR from here.
+   ```
+
+2. Once this PR is approved and merged, the next steps would be conversion,
+   version update, automatic update of History.md, and release (steps 6–10).
+
+This is based on an issue [#18][].
+
 ### Contributors
 
-* Austin Ziegler created mime-types.
+- Austin Ziegler created mime-types.
 
 Thanks to everyone else who has contributed to mime-types:
 
-* Aaron Patterson
-* Aggelos Avgerinos
-* Andre Pankratz
-* Andy Brody
-* Arnaud Meuret
-* Brandon Galbraith
-* Chris Gat
-* David Genord
-* Eric Marden
-* Garret Alfert
-* Godfrey Chan
-* Greg Brockman
-* Hans de Graaff
-* Henrik Hodne
-* Jeremy Evans
-* Juanito Fatas
-* Łukasz Śliwa
-* Keerthi Siva
-* Ken Ip
-* Martin d'Allens
-* Mauricio Linhares
-* nycvotes-dev
-* Postmodern
-* Richard Hirner
-* Richard Hurt
-* Richard Schneeman
-* Tao Guo
-* Tibor Szolár
-* Todd Carrico
+- Aaron Patterson
+- Aggelos Avgerinos
+- Alessio Parma
+- Alex Balhatchet
+- Andre Pankratz
+- Andrey Eremin
+- Andy Brody
+- Arnaud Meuret
+- Bradley Meck
+- Brandon Galbraith
+- Chris Gat
+- David Genord
+- Eric Marden
+- Garret Alfert
+- Godfrey Chan
+- Greg Brockman
+- Hans de Graaff
+- Henrik Hodne
+- Jeremy Evans
+- John Gardner
+- Jon Sneyers
+- Jonas Petersen
+- Juanito Fatas
+- Keerthi Siva
+- Ken Ip
+- Łukasz Śliwa
+- Lucia
+- Martin d'Allens
+- Mauricio Linhares
+- Myk Klemme
+- nycvotes-dev
+- Postmodern
+- Richard Hirner
+- Richard Hurt
+- Richard Schneeman
+- Robert Buchberger
+- Sergio Baptista
+- Tao Guo
+- Thomas Leese
+- Tibor Szolár
+- Todd Carrico
+- Yoran Brondsema
 
 [qcm]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
 [rmt]: https://github.com/mime-types/ruby-mime-types/
+[#18]: https://github.com/mime-types/mime-types-data/issues/18