I wouldn't bother with reducing the revision number. If anything having weirdly high ones makes the project seem more alive and active. Is the minor number even functionally useful here? Maybe we should ditch that and just keep major as a "look! An increment! Heaps cool stuff must have happened!" unless google chrome has ruined new major numbers for everyone anyway.
— Jenna On 02/10/2011, at 10:43 PM, Magnus Holm <[email protected]> wrote: > I'm thinking of releasing 2.1.458 which includes a few more features > (better cookie support, inline templates etc), but mainly to fix some > incompatibility issues with Rack. I'm not going to document the new > features yet, so consider them experimental in this patch-release. > > As for the version, it's currently MAJOR.MINOR.REV where REV = number > of commits since the beginning. It works pretty well to use REV as a > part of the version number because I can then easily throw out > experimental releases to my gem server without screwing up the version > number. However, from 2.2 I'm thinking of changing REV to "number of > commits since previous release", simply to avoid some high revision > numbers. > > Thoughts? Okay with a little maintenance release? Okay with some > undocumented experimental features? Okay with REV? Okay with > decreasing REV a bit= > > // Magnus Holm > _______________________________________________ > Camping-list mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/camping-list _______________________________________________ Camping-list mailing list [email protected] http://rubyforge.org/mailman/listinfo/camping-list
