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 active1. 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 repository2. 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.


  1. 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.
  2. 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.
Tags//

A Message from the Ansible

Have you gotten the Ansible working yet?

Not quite yet. Just a little more tweaking. Ah, there we go.

Yes, that’s much better. We’re now back online.

Markdown: Generating Heading IDs

In late October, I submitted a pull request (#125) to blackfriday, a Go package for processing Markdown, in order to satisfy a feature request deemed useful for Hugo (GitHub-style header generation).

Bastille in Toronto, October 2014

I saw Bastille last night at the Air Canada Centre, and “Bad Blood: The Last Stand” was a pretty damned good show.

Plumage: A RubyMotion CLI App

I wanted to play with terminal.sexy1 recently to see if I wanted a different terminal colour scheme—but as I use Terminal.app, I needed to convert the colour scheme to the iTerm 2 format for import.


  1. A Terminal Color Scheme Designer, via One Thing Well.

Ruby Net::LDAP Under New Management

TL;DR: Net::LDAP for Ruby is under new management: Michael Schaarschmidt (@schaary). Back in 2003, I registered the net-ldap project on RubyForge. I had time available, and I thought I needed LDAP for a project I was working on. As I started looking at the implementation of LDAP, I found that there were things more interesting and more pressing that I could work on. Then, as now, I wasn’t sure that I wanted to understand LDAP.

New GPG Key

mime-types for Io

Welcome back. I haven’t posted here in five and a half years and the website has been offline for at least two years, but that will be changing, starting now.

I recently finished reading Seven Languages in Seven Weeks. As an exercise, I ported mime-types for Ruby to Io on the 17th of September.

Series: Seven Languages

FOSSLC Panels and Me

I’ve been extraordinarily fortunate recently to be invited to participate in two panels presented by FOSSLC and hosted by the University of Toronto.

Mac Recipe Management Programs, Planning a Revisit

Mostly through a couple of bundles that I’ve purchased recently, I have acquired full licences to Acacia Tree Software’s SousChef and MacGourmet Deluxe (which is, remember, MacGourmet with all of the plug-ins included).

Mac Recipe Management Programs

It’s time to declutter the house. One of the things I want to get rid of are all the recipe magazines and loose recipes that I have. To do this, I need to keep the recipes that I like or want to try. I need a recipe management program. I currently use Yum 2.7.4, which is good, but not great. I decided to seriously evaluate the various recipe management programs available for the Mac.

Aw, Damn (Au Revoir, M Decoux)

Vacationing with the iPhone

A Legend Passes

More Old Magazines

Amnesty International Condemns Canada on Death Penalty

Medical Office Magazine Collections

There’s a Ruby debugger?

Why I (now) wholeheartedly support MMP

Andrew Coyne: Why conservatives should support proportional representation

Is there anybody going to listen to my story…

On Derek Sivers return to PHP…

Ontario Votes: Voting Format Referendum

Beyond time

RubyConf 2006—Day 3 (Sunday, 22 October 2006)

RubyConf 2006—Day 2 (Matz’s keynote, Saturday, 21 October 2006

RubyConf 2006—Day 2 (Saturday, 21 October 2006)

RubyConf 2006—Day 1 (Friday evening, 20 October 2006)

RubyConf 2006—Day 1 (Friday, 20 October 2006)

RubyConf 2006—Day 0 (Thursday, 19 October 2006)

Ruby on Windows: A Note for Microsoft

D*ck T*ping and Semantics

ARIEL: A Mentor’s Mini-Review

Vacation Rubyist Meet Wrapup

Deutsches Rubyists

London Ruby Users Group

Rubyists in London, Germany, Amsterdam?

Eggplant Curry

Pumpkin Cheesecake

Complex Data Structures in PL/SQL

An Extremely Brief Introduction to PL/SQL