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 13:28:12 -0700 (PDT)

--- Martin Rubey <address@hidden> wrote:

> 
> Make it print
> 
>      Axiom 7.3 (gold, 679)
> 
> and they'll say "wow".

Heh - true.  I suppose that could work, but I'm not sure it would
convey what really should be expressed by such numbers (see below.)

> (Curiously, it is easier to produce a version
> number that carries information like the one above, than a version
> number like 4.1 that doesn't carry any information at all.)

4.1 may not convey any technical information, but it DOES convey
information.  If the previous version was 3.0, the user expects 3.0.1
to be a minor fix (they probably won't directly see any change unless
they're triggering a specific bug that was fixed) 3.1 to have some new
features or significant fixes, and 4.0 to be a major improvement over
the 3.x series.

These types of versions are a marketing tool, telling customers in very
brief terms what their expectations should be.  For example,
Mathematica's new version 6 is a major version increase.  So
significant changes can be expected compared to the 5.x series - the
jump of the major version number indicates this.  Most software uses
this approach, in one form or another.  Maxima certainly does.

So you are corret that X.Y conveys less information than
yymm.branch.revision, but the X.Y version does more to tell the user
what to expect.  Major changes?  Minor fixes?  What does this new
version do?  X.Y is supposed to convey this (not that all projects get
it right, but in my experiences many of them do.)

> > Not silver, not branches, JUST gold.
> 
> At least here in Austria, most people use wh-sandbox. 

Now, that's true.  Eventually, we should reach the point where users
should be using Gold by default.  There are too many things that need
fixing for this to happen at this time.  That will change as Axiom
matures as an open source project, and we get a foundation strong
enough to let us focus on new mathematical work.  Until that point, we
aren't ready (in my opinion) for general consumption anyway.

So I agree Martin - right now people are using wh-sandbox.  What I'm
saying is in the long term we should have Gold in a state where people
will use it by default without feeling the lack-of-features pinch, and
when we get there I would like the numbering scheme used for Gold
releases to respect the common convention used by virtually all
software to communicate the magnitude of changes in releases.  It
doesn't replace any of the development schemes, so developers won't
have to care unless dealing with a bug report - and then they can
quickly decode the release # into what they need.  Does that seem
reasonable?

> (Surprisingly,
> at least to me, Austrian researchers seem to embrace Axiom: 
> MathAction lists Austria with 2% before Canada, Russia and China, 
> each with 1%.  Not bad, eh ?

Cool :-).

> altogether there are only roughly 8 million Austrians...)

Well, if y'all are using Axiom you won't need as many ;-)

Cheers,
CY


       
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/




reply via email to

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