Axiom, which uses git, releases every 2 months.
The "version number" is given as month, year as in
the "May 2010" version.
Reading meaning to various Godel numbering schemes
(aka 188.8.131.52 or F37D4A55...) makes for endless discussion.
Visit any project discussion group to see the same points
made in every possible permutation of opinions. Is it
really meaningful to change 184.108.40.206 to 220.127.116.11?
Since official releases never go below monthly values
there is no reason to sub-code for these cases.
Tobias C Rittweiler wrote:
> In article <BBD7CE5A-5867-4D81-9A3B-11417FD5BFC3@...>,
> James Y Knight <foom@...> wrote:
>> On Jun 19, 2010, at 11:07 PM, Alastair Bridgewater wrote:
>>> Hello all,
>>> A while ago I was told that the major hangup on moving the system of
>>> record for SBCL source control from CVS to something more modern was
>>> the lack of good support for maintaining our present version-numbering
>>> scheme. To that end, attached are a short article I wrote "On
>>> Automatically Setting the Version Number for SBCL Commits Using Git"
>>> and a shell script that goes with it.
>> Is all this complication really necessary?
>> I mean, I guess if this is the reason for not switching from CVS yet,
>> fine, I'm all for doing something like this to get the switch going...
>> But wouldn't it be simpler to just do away with the sub-release
>> version-number? I'm not sure I know of any other project that uses
>> such a scheme, and they all seem to be fine with it. It was useful
>> when using CVS if only to be able to have something to run "cvs log"
>> on. But I'm not sure I see why it needs to be preserved.
>> Could just use the git hash instead as a sub-release identifier, for
> I quite like the structured version identifiers for they're so
> much more human friendly in discussions. I usually use planet.sbcl to
> read about context of a particular commit, as long as the commit
> in question is reasonably recent which it most often is.
> It's also easier to ask someone having a problem, "What version
> are you running on?", and then you can usually quickly decide
> whether or not that version is before or past a particular
> commit you know of being problematic or crucial in some way
> related to the description of the problem.
> How do projects using the git hash deal with this?
> FWIW, ASDF seems to use a similiar policy but, arguably,
> it was copied from SBCL.
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> Sbcl-devel mailing list