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

[C Y]

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

> I find it extremely hard to classify many of the recent (i.e., last
> few months) changes in wh-sandbox as minor.  May well be that only 
> a single line in the algebra sources was modified, but still, if the
> result was wrong before and correct after, this may well affect long
> computations.

That's true, of course.  That's one of the reasons I hope we can
incorporate some formal proof software and be really sure our
implementation will produce correct results.
 
> Fortunate as we are that Axiom is gratis, I suggest that serious
> users should svn up as often as they can.

Yes, but they will also want to avoid the breakages that come with any
development cycle.  It's a tradeoff.

> But I admit that there are landmarks.  HyperDoc in wh-sandbox was one
> for me. Hm, in fact, I do not know of any other landmark.

HyperDoc has been the most recent user visible landmark.  Working
graphics was one as well.

> I don't care whether axiom uses autoconf or not, to be honest.  If
> Waldek and Gaby say autotools make maintainance easier, OK.  If Tim
> says, it doesn't, OK.

It's an indirect issue, true.  The consequence will be better
portability down the road.

> > > 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.  
> 
> Cliff, please stop thinking about the future. 

On the project with the 30 year horizon, you want me to stop thinking
about the future?

> Well, one month is OK, but three months is certainly not *now*.  If
> you want to implement a versioning scheme, please implement one that
> works with the current situation.

But we do have one that works with the current situation -
yymm.branch.revision.  That's a development versioning scheme, and I
think it's a good one.  We should go with it for anything that's not
Gold.  Right now, that's everything useful - granted.  So we can
recommend new users try 0725.wh-sandbox.600 (or whatever the latest
revision is.)

It sounds like if we can make the right kind of change set, we can make
fairly rapid process on phasing things in to Silver.  If I ever get a
decent machine up and running again I'll try and help with that.  It
sounds like it should go:

1)  Tim's fix for the Win/Mac filename issues - then we can checkout on
multiple platforms
2)  Gaby's autoconf introdution.
3)  Working out the migration path from Silver as it currently exists
to Waldek's ANSI code.  Involved, but probably doable - I'll try to
help if I can.
4)  HyperDoc support.  This may come after #2 depending on details.
 
> If you implement one that works for Gold only, forget it.

No, no - not "works for Gold only" - it's FOR Gold.  That means right
now, it won't be very visible.  (I.e. it shouldn't annoy anybody.) 
Development versions should eventually be "behind the curtain" for
those who want to look, with releases being the public face of the
project.  Distributions are only going to want to build binaries for
distributions once in a while - they need a "let's include Axiom
version 5.1" target.  

Officially, the cvs Gold tree is the stable Axiom as put out by the
Axiom project.  That is a problem, but it is one I think we should
address rather than just throw up our hands fork with wh-sandbox.  We
have improvements to merge in, but Tim has a quality assurance process
to put them through and I can see why that should be done.  I have
little doubt they will pass - Waldek does good work - and there is
nothing to stop people from using any tree they wish in the meantime.

yymm.branch.revision will work fine for the current situation - when we
are ready to start going after market share, we want something more
conventional.  That future, where the project itself has a customer
ready version, is what I am thinking about.

So Martin, I'm off your radar - I'm in the future and can be ignored
:-).

I really want to be able to bring these efforts back into a unified
project, and I'd like to do what I can to help make that happen.  It
sounds like diff -Naur patches that isolate subjects are the key, so
I'll try to push in that direction.  It sounds like Tim has the first
one, Gaby is obviously the best qualified for the second, and the third
will be a lot of work to identify the purposes of various changes.

Tim - one question.  If Waldek is right and it proves very difficult to
produce working intermediate steps for these change sets (ANSI in
particular), would you settle for patches which implement changes that
relate to a concept but depend on another patch to actually reach a
working build state?  Otherwise we may wind up with a patching version
of a bootstrap problem, and that will be pure unmitigated nastiness for
minimal gain.

Cheers,
CY


       
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, 
photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC