TRANSCODE Explorations into the Code Transcendental.

Plethora of Version Versions

The Plethora of Version Versions

A couple of my programs have need of a Version API –a library for handling version numbers, and handling them well. Not only do they need a class modeling a version number, but also a version constraint and in one case even a version conflict resolver for requirements. Presently each project had its own code for handling versions. But as these projects have evolved it has became increasingly clear that effort was being wasted and that I should pull the separate bits of code together into a single gem on which they all could depend.

So I created the new project –actually it was some time ago, but I ran into that not-so-unusual snag, what to name it. Unfortunately there was already a version gem, and could think of no better name. So I put the whole thing on the back burner for some months. Today I finally returned to the question. I still don’t have an answer, but to be thorough I searched of RubyGems.org using “vers”. I thought there were a lot of ANSI code gems!

The majority of these gems address the same functionality, that of bumping a version number. Some of those provide rake tasks to do so, others just the API, and a couple go a step further handling git commits and gem pushes as well. One a few actually focus on modeling a version number, though all have some sort of internal model no matter how simplistic. Only one appears to provide a model any more sophisticated than simple comparison and accessing named components (major, minor, patch, etc.). SemVersion also has simple constraint testing.

It’s too bad there is not more cooperation among gem developers. I think this is an area in which the Perl community has shined. Surely in no small part to CPAN and the culture of naming libraries functionally, rather then creatively.

Still doesn’t help me name mine.


Note Versionable is something different, and pretty neat.