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
email
is based on my post:
<http://www.halostatue.ca/2015/04/the-mime-types-project/>
## 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 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.
<https://metacpan.org/release/MARKOV/MIME-Types-1.003>
<https://metacpan.org/release/MARKOV/MIME-Types-1.004>
‡ Ideally, the mime-types project should have a monthly (or more
frequent)
release because of the IANA data updates. Equally ideally, this
release
should be almost completely automated.
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).
<https://rubygems.org/gems/mime-types/versions/2.0>
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.
<https://github.com/liluo>
<https://github.com/liluo/mime>
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.
<https://github.com/mime-types/io-mime-types>
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.
<https://github.com/mime-types>
<https://github.com/mime-types/ruby-mime-types>
<https://github.com/halostatue/mime-types>
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.
‡ This will be applied retroactively after the data has been separated
from
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
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.
<https://github.com/mime-types/ruby-mime-types/milestones/3.0>
-a
···
--
Austin Ziegler • halostatue@gmail.com • austin@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue