[Axiom-developer] Version numbers and merging improvements

[C Y]

I'm not quite sure if I should risk muddying the waters further, but I
have (sort of) an idea and perhaps it would make sense to other people.

If we step back and take a look at the requirements driving various
aspects of this debate, I think the main points are:

1.  Most open source software uses a numerical X.Y.Z style numbering
system for released versions of software.  This is common enough that
package management systems (Gentoo for example) are best suited to work
with such arrangements.

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.

3.  The branches build-improvements and wh-sandbox have many fixes and
pieces working that the "official" Silver and Gold do not - reasons for
this are complex.


For the first and second points, we want to both make Axiom a good fit
with packaging systems and preserve the useful information we need.  I
would suggest the following, a minor variation on some existing
proposals:

1.  We establish two fields to hold version numbers - the current
mechanism and a "release version" slot specifically for use when
updating Gold.  The "release version" would use X.Y.Z style numbering,
and would correspond exactly to a particular branch of Gold.  When the
banner of a Gold release is run, it would find the release version set
and print that as opposed to the more detailed (and confusing, to the
casual user) branch and revision information

2.  In any branch other than gold, the release version is nonsensical
and would remain unset.  Because it is unset, the current mechanism
would take over and print branch and revision information - exactly
what a developer needs.

This has the merit of simplicity - it should be borderline trivial to
code - and returning the appropriate information for a given situation.
 Developers get development information, Gold users get something
simple they can understand.  If we need to relate it to a branch and
revision, the branch is Gold and the revision is the revision tagged
for release X.Y.Z.  If that sounds good to everyone I'll volunteer to
cook up a patch that can be merged into both Gold and Silver to
implement it.

OK, well and good, but proposing such a scheme doesn't make it so.  I
think most of the practical problems relate to #3 above:

Merging build-improvements and wh-sandbox.

There are a great many changes in these branches, and making sure they
are understood is important.  First an observation, and then I have a
suggestion for handling this that ties in with the above numbering
scheme.

Observation:  If I understand correctly Tim (please correct me if I'm
wrong) you are being careful about introducing changes into Gold
because you want to avoid regression of functionality and ensure that
changes included in Gold are correct?  This is one of the motivations
for the new regression testing system, IIRC - to make testing these
changes faster.  I certainly agree that such a system is needed, but
I'm not sure if we need it for all the changes being considered at this
current point.  I could be wrong, but this is my thinking:

1.  At the current state in the design and development of Axiom, we
have no more reason to be sure Axiom is correct than any other CAS,
except for the modes of thinking and programming encouraged by its
strong type system.  There is no formal verification system backing the
current codebase or builds.

2.  Regression testing will identify unintended consequences of changes
in the code, but it will not identify correct vs. incorrect results. 
For that we need the CATS effort, and probably some formal correctness
proof systems mixed in there.

3.  Given these facts, it might be of slightly less importance to do
exhaustive regression testing for every change until we risk not just
side effects but undermining trusted results.  Or, stated another way,
what is our loss in confidence in the correctness of an algebra result
as a consequence of changes in the current codebase?  Do we have
confidence to begin with?

Obviously in some situations (like the algebra bootstrap) we have to
check.  Others (ANSI compatibility changes, hyperdoc) I personally am
less nervous about - I think there is enough work to do at all levels
of the system that any problems introduced by those changes will be
rooted out in the gradual literate programming process - particularly
at the levels below the algebra, which I think will need extensive work
before we're done.  Given that work will need to be done regardless,
I'd much rather be working from an ANSI foundation.

Proposed merge and release scheme:

1.  Take the current Gold CVS tree, fix any truly obvious and trivially
fixable problems and assign it the version number 3.0.0.  This should
be the last version not based on ANSI Common Lisp.  

2.  Identify the changes needed in wh-sandbox to enable building on
ANSI, and merge them.  This may not be separable from fixing some bugs
in things like the database bootstrap, but we will see.  The next goal
should be getting Silver up to the point of running on ANSI lisps,
IMHO.  Once that is accomplished, merge Silver into Gold and release
the new Gold as 4.0.0 - the first stable ANSI based Axiom.

(Note:  If a Lisp based build of the core Axiom code is possible in
4.0.0, it should be possible (give or take some filesystem quirks) to
build an AXIOMsys Windows release with nothing but a working ANSI Lisp
as the bootstrap requirement - if that's the case a first Windows
release needn't wait on the autoconf machinery and GCL.  Eventually I
would like both, but any ANSI should work for that first release while
we hammer out the issues, and that would mean a Windows binary actually
based on the main trunk would be available.)

3.  Once ANSI merge is accomplished, work on merging the build
machinery.  It should be possible, like Maxima, to build in different
ways depending on what tools one wants to use - autoconf has undeniable
advantages when it comes to integrating and managing things like the
gcl build and the sman and graphics.  Once we have autoconf working in
Silver, release 4.1.0 in Gold.

(If autoconf in Axiom is anything like autoconf in Maxima, autoconf
handles all the non-lisp-based details and triggers the Lisp build
system for the core system.  It may also handle dumping the core
images, which (of course) can't be done from inside the lisp build
process.)

4.  Then, we can introduce the fixes that get hyperdoc working.  This
would be version 4.2.0 in Gold.

Algebra fixes can be scattered throughout - if they rely on core level
fixes like the new database bootstrap procedure we will need to sort
that out at the 4.0 stage, but I think that should be doable.  It would
be really nice to be able to include Martin's working Guess package in
4.0.

This of course still leaves us with the hard work of getting the ANSI
changes into Silver (I'm working on learning GIT, and once I get
something other than this old laptop running I can make a more serious
stab at it).  Does this plan look like it makes sense, Tim? 
(Everybody?)  We may find that after 4.0 we release 4.1 quickly and 4.2
on the heels of 4.1, but that's fine.  Hopefully by 4.2 we will have
Gold up to the current wh-sandbox functionality level, and the
motivation for the different branches will disappear.

Tim, Gaby, Waldek, all - opinions?


Cheers,
CY


       
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. 
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469