The mime-types Project

I am making changes to how I’m going to be running the Ruby mime-types project moving forward, and I made the first step in those changes last night. These changes won’t be fully finalized until later this year. This article outlines those changes that have been started and where they will be finished.

Background

The Ruby mime-types project is one of the oldest projects in the community, but the number of releases does not make it seem very active¹. It was first created and release (as 1.003) in October 2002 (based on the release dates of Perl MIME::Types 1.003 and 1.004, which I tracked). Over the next few years, I would periodically update mime-types, but it would sometimes sit for years without a change (1.15 to 1.16 was over three years). For the most part, it just worked, and it didn’t matter—until there was a new MIME type that someone needed or their use case found a bug.

Almost two years ago, I released mime-types 2.0, dropping support for Ruby 1.8 (and deliberately using syntax not supported in Ruby 1.8 to enforce that decision). Aside from that breaking change, mime-types 2.0 changed its type registry from a flat-file representation (requiring a custom parser) to YAML for editing (easier on developers) and JSON for use. The amount of data in the registry was also substantially increased (this led to some memory problems, although the performance was better overall—and various contributions to the code improved that further).

The code of mime-types has also been ported at least twice:

1. liluo ported mime-types to Python (as mime). It is based on the old 1.x data format, but it would not be hard to bring it up to speed.

2. I ported mime-types to Io. Mostly as an exercise, but also because I think that the library I have provided here is useful.

In the last year, I also started getting interesting feature requests—not all of them directly compatible with one another. Plans toward a 3.0 release could be made. But I don’t think that I can do this alone—nor do I want to give it up entirely as I have done with libraries in the past (PDF::Writer some years ago and net-ldap more recently).

Getting Organized

To address this desire (opening up), I have created an organization on GitHub, mime-types. I have moved the repo to mime-types/ruby-mime-types, but have kept a fork at halostatue/mime-types so as not to break any remotes or Gemfiles pointing there. I have also moved halostatue/mime-types-io to mime-types/io-mime-types, again keeping a fork in the original location. I also have a fork of mime as mime-types/python-mime-types that will probably be addressed later.

Over the next few months, I am going to extract the registry management tools from ruby-mime-types so that updating those tools is much easier—and independent of—the main mime-types library. This is going to be core to the 3.0 release of ruby-mime-types: the data will no longer be intrinsic to the library, but instead be expressed as a dependency. Over time, I will hopefully have tools that can automatically produce data releases without intervention.

For the rest, I am moving to an open commit bit. I’ll still want contributions to match my style, but if you’ve had an accepted code change to any repository, you will have full commit access to that repository². Releases are going to be opened as well, but not as freely—there are too many gems that depend on ruby-mime-types.

ruby-mime-types 1.x Full EOL

When I released ruby-mime-types 2.0, I made a commitment toward security fixes (if any) in ruby-mime-types 1.x, but neglected to set an End of Life date. I am correcting that oversight:

ruby-mime-types 1.25.1 will be fully EOL on 2015-10-27.

I am already not accepting bug reports or new MIME content-type requests; that happened shortly after the release of 2.0. As of that date—two years after 2.0— the 1.x branch of ruby-mime-types will be fully closed.

mime-types 2.x Future and EOL

I am ramping up on development of ruby-mime-types 3.0 fairly soon. There are two releases left in the 2.x series:

• 2.6 will add a columnar data approach, if such approach can be done without breaking backwards compatibility. The current implementation requires introducing some extra classes that I do not plan on carrying to 3.0, so the specifics of the implementation will not be documented until the 3.0 release. This is to address a few issues encountered by some users.

• 2.99 will be a transitional release. All of the interfaces marked deprecated will be set to maximum noisiness, and the registry will not include data for deprecated fields. This may break some code, but the warnings have been in place for nearly two years. The methods will still be there, but the data will not.

  2.99 may depend on a mime-types-data gem, but that is not yet determined (it will depend on how hard it is to backport this to the 2.x line from 3.0 where it will be built).

After the release of 2.99:

• No new feature requests for 2.x will be accepted.
• Bug fixes and registry changes will be accepted for one year.
• Security fixes will be accepted for two years.

On the second year after the release of 2.99, that branch will be fully closed.

mime-types 3.0

I have a lot of ideas for the future. Some of these are marked in the 3.0 milestone. Some are still in my head. But the future of mime-types isn’t just what I’m going to make it—I want and need your feedback, your issues, and your code, too.