axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Version numbers and merging improvements


From: C Y
Subject: Re: [Axiom-developer] Version numbers and merging improvements
Date: Mon, 25 Jun 2007 12:18:17 -0700 (PDT)

--- Martin Rubey <address@hidden> wrote:
> > 2.  When debugging Axiom, the most useful information is the branch
> > and revision used to build the binary - we want to preserve this
> > information in a form that can be easily accessed at need.  The
> > current banner report reflects this.
> 
> No it does not.

OK, sorry - I'll look closer at it when I get home.

> Since wh-sandbox is currently one of the best
> working flavours of axiom, you must not ignore it.

Um - I don't propose to.  I have not given up on merging the wh-sandbox
build improvements back into Silver, and eventually to Gold.

> Switching to yet another version scheme is, in my opinion, stupid and
> misleading.
> 
> PLEASE don't.

Martin, I'm not going to arbitrarily implement any scheme - that's why
I'm discussing it on the list.  Nor am I proposing a switch, in the
true sense - I am proposing a numbering system for Stable releases
intended for end user consumption.  To date, we haven't had many of
those.

> Personally, I like the version scheme yymm proposed and consistently
> used by Tim.  It does lack some information, unfortunately, so I
> proposed to extend it to
> 
> yy.mm.branch.revision-number.

This is acceptable for development tarballs, but I personally think it
is going to look strange to most users if we use it for stable
releases.

> Merits:
> 
> * Gaby agreed, I don't know about Waldek.
> 
> * it doesn't add yet another versioning scheme.
> 
> * it is crystal clear.

My own opinion (and this is JUST my opinion) is that any numbering
scheme for STABLE RELEASES which doesn't follow the Major.Minor system
for release is going to look very odd to users.  Remember the version
number for a computer algebra system is part of its basic marketing
material - Maple 5, Mathematica 6, Maxima 5.9.3, etc.  When people talk
about Mathematica 5 vs. Mathematica 6, it is instantly clear.  If we
say Axiom 0703.gold.679 (for example), the first response of a
non-developer is going to be "what?"  The second will probably be "if I
can't understand the Version number, what will the rest of the system
be like?"  "Axiom 3.0" or "Axiom 4.1" would be a lot easier to say and
refer to.

So let me be clear - I am proposing we use an X.Y numbering system ONLY
for new Gold releases.  Not silver, not branches, JUST gold.  And that
version number can be translated into information like dates and
revision numbers, if we need to.  Since Gold releases will be what the
distributions (and end users) should focus on, in my opinion numbering
it in a way they expect will make things simpler.  Silver et. al.
shouldn't ever need tarballs or binaries, once the main Silver branch
and a Gold release can build on the target platforms with the key
features.

Cheers,
CY


       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play 
Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  




reply via email to

[Prev in Thread] Current Thread [Next in Thread]