Friday, July 24, 2015
The new way to version software
The Complete Drone-Ver Specification
This also lives at drone-ver.org.
Drone-Ver v.1.sleepy.0.0.calamitous.1437363538.7
Summary
Given a version number MAJOR.MOOD.ISSUES.SOCIAL.DICTIONARY.UNIXTIME .SEVEN, manage your releases as laid out in this comic:
- MAJOR is incremented when you feel like you've added something cool.
- MOOD is how you felt when you released this version.
- ISSUES is the number of open GitHub issues against your project.
- SOCIAL is the number of GitHub forks & favourites of your project.
- DICTIONARY is a random dictionary word.
- UNIXTIME is the unix time, and
- SEVEN is always the number seven (7).
Via Brian Yoder, Cube Drone - - Version Sacrifice
This is clearly a satirical response to Semantic Versioning as there are some who don't like
it. I found the Drone-Ver stuff hilarious (why yes, I am a geek—why do
you ask?) and according to it, mod_blog should be at version
28.bemused.0.3.chinnier.1437723165.7 (assuming bug fixes are
“something cool”) instead of the current version of 4.7.5.
But I also found Semantic Versioning to be a decent attempt to make version numbers have some semantic meaning. Semantic Versioning seems to be geared more towards libraries, and if there was one change I would make to it, it would be that minor versions (backward compatible changes or enhancements) shouldn't break user code (so that if you have a program that uses Foo major version 4.0.n, it should compile cleanly against 4.1.n, 4.2.n, etc. since they all should be compatible) but that bug fixes might break user code (if, for instance, you worked around it, or somehow used the bug as a feature of your code) but if you used the API as described, things should be okay.
Semantic Versioning breaks down for applications though, as there is no real API to speak of (which causes a change in the major version number). I think a good approach for applications with Semantic Versioning is that a major version should only change if configuration or data files change format (such that the new format is incompatible with the older format, or the older version can't load newer versions of the configuration or data files), new features or enhancements cause the minor version number to update, and bug fixes bump the patch version.
Using that criteria, mod_blog would be at version
2.7.5—there was a configuration file format change when I
switched from using my own half-baked configuration format to using Lua as the configuration
format (otherwise, the storage format for mod_blog hasn't
changed one bit in fifteen years, although it has been enhanced, older
versions would be able to deal with the newer information by simply ignoring
it).
And just for the record:
| date released | version | comment |
|---|---|---|
| Sat May 30 23:48:18 2009 -0400 | v2.0 | Yet another idea to add to the blogging engine |
| Mon Jun 22 19:51:15 2009 -0400 | v3.0 | Removed more dead code. |
| Wed Sep 9 03:22:07 2009 -0400 | v3.1 | Feature: Replaced how we pick the adtag |
| Wed Sep 9 17:45:17 2009 -0400 | v3.2 | Feature: Some more template defs |
| Sun Nov 6 02:01:41 2011 -0500 | v3.3 | Lua configuration |
| Sun Nov 6 02:01:41 2011 -0500 | v3.4 | Document current bug in source code |
| Mon Nov 14 22:51:10 2011 -0500 | v4.0 | Made sure the dependencies were correct in Makefile |
| Tue Nov 6 14:37:10 2012 -0500 | v4.1 | Removed internal entry cache |
| Mon Dec 31 22:46:01 2012 -0500 | v4.2 | The 'Gasp! Released at Last' Version |
| Mon Mar 3 17:57:00 2014 -0500 | v4.3 | The 'Clean Memory' Version |
| Fri Jun 27 03:02:24 2014 -0400 | v4.4 | The 'MyGoogleFaceSpacePlusBook Fix' Version |
| Thu Aug 21 17:10:07 2014 -0400 | v4.5.0 | Display version of libraries used, in addition to the version of the program. |
| Sun Apr 19 19:08:46 2015 -0400 | v4.5.1 | The 'Make the Makefile makier' Version |
| Sun May 3 02:19:23 2015 -0400 | v4.6.0 | The 'XXXX FaceGoogleMyTwitterPlusSpaceBook' Version |
| Fri Jun 5 21:53:54 2015 -0400 | v4.6.1 | Bug fix—double free |
| Sun Jun 7 19:48:09 2015 -0400 | v4.6.2 | Bug fix—if not using email notification, code doesn't compile |
| Sun Jun 7 20:03:00 2015 -0400 | v4.6.3 | Bug fix—don't use _IO_cookie_io_functions_t |
| Sun Jun 7 21:51:40 2015 -0400 | v4.6.4 | Bug fix—potential double free (yet again). |
| Sat Jun 27 18:09:27 2015 -0400 | v4.6.5 | Bug fix—encoded entries via email mess things up. |
| Thu Jul 2 17:38:09 2015 -0400 | v4.6.6 | Bug fix—unauthorized person posting via email leads to double fclose() |
| Mon Jul 6 17:53:30 2015 -0400 | v4.6.7 | Bug fix—a NULL tumbler crashes the program. |
| Sun Jul 19 17:08:43 2015 -0400 | v4.7.0 | The 'Tumblers Reloaded' Version |
| Sun Jul 19 22:28:18 2015 -0400 | v4.7.1 | Bug fix—date checking on exiting tumbler_new() was borked. |
| Mon Jul 20 01:25:46 2015 -0400 | v4.7.2 | Bug fix—previous and last calculations were borked. |
| Mon Jul 20 04:00:34 2015 -0400 | v4.7.3 | Bug fix—check tumbler date(s) against last entry, not the current time |
| Mon Jul 20 17:52:24 2015 -0400 | v4.7.4 | Bug fix—current link was wrong |
| Fri Jul 24 03:32:45 2015 -0400 | v4.7.5 | Bug fix—the assert() when comparing dates was wrong |
The history prior to version 2.0 is … um … murky. I had …
issues … with the previous version control system so pretty much the history from December 1999 through May 2009 have been lost in time, like
tears in rain. As you can see, the version numbers have been inconsistent
early on, but as time went on, I've done a bit better with the version
numbers (it's been more consistent with 4.6.0 onwards).
