Notes on the future of the mime-types project

I just released mime-types 2.5 late Friday, and I wanted to point out to
readers here some plans about the future of the mime-types project. This
is based on my post:


## Background

The Ruby mime-types project is one of the oldest projects in the community,
the number of releases does not make it seem very active‡. It was first
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
periodically update mime-types, but it would sometimes sit for years
without a
change (1.15 to 1.16 took 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.


    ‡ Ideally, the mime-types project should have a monthly (or more
      release because of the IANA data updates. Equally ideally, this
      should be almost completely automated.

Almost two years ago, I released mime-types 2.0, dropping support for Ruby
(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
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
    that the library I have provided here is useful.


In the last year, I also started getting interesting feature requests—not
of them directly compatible with one another. Plans toward a 3.0 release
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
and net-ldap more recently).

## Getting Organized

To address this desire (opening up), I have created an organization on
mime-types. I have moved the repo to mime-types/ruby-mime-types, but have
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
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
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
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
have tools that can automatically produce data releases without

For the rest, I am moving to an open commit bit. I’ll still want
to match my style, but if you’ve had an accepted code change to any
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.

    ‡ This will be applied retroactively after the data has been separated
      the code; people who have submitted registry changes will get commit
      access to mime-types-data, and people who have submitted code changes
      will get access to ruby-mime-types.

## ruby-mime-types 1.x Full EOL

When I released ruby-mime-types 2.0, I made a commitment toward security
(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;
happened shortly after the release of 2.0. As of that date—two years after
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
    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
    (it will depend on how hard it is to backport this to the 2.x line from
    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

## 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
your issues, and your code, too.




Austin Ziegler •