William Stein wrote:
On Wed, May 26, 2010 at 3:08 PM, Tim Daly <d...@axiom-developer.org> wrote:
The Axiom project had a long debate about releases
and version numbers which I see is about to happen here.
Axiom decided that a reasonable balance was to make 2 decisions,
one about releases and one about versions.
RELEASES
There is a choice between releasing often and releasing,
say, yearly. Sage releases about every week or two at the
moment. The upside of this strategy is that people get the
latest version immediately. The downside of this strategy
is that people are ALWAYS in update mode and big changes
are very hard to manage in a small window (2 days?)
First, there would be a "silver" and a "gold" releases. The
silver version is updated continuously and available from
most of the sites with a git pull or git clone. The "gold"
release would be a time-boxed release every 2 months.
This gives people who care about a particular change a way to
get the latest release immediately. It allows others who just
want "the system", a way to update at a more reasonable pace,
maximally, every 2 months. The "gold" release is maintained
on github, the "silver" is on all other sites.
VERSIONS
Version numbers get religious really fast and the debate is
not very productive. Essentially, a single number is not
sufficient to carry all of the information about what might
have changed, especially if you have a component system.
Since git maintains a 40-digit SHA1 hash for every commit
it is sufficient for a version number. Any reference to a
single hash number gives all of the required information.
This is sufficient for "silver" releases.
Since the time-boxed "gold" releases are 2 months apart it
is sufficient to use the form "May 2010" as the unique
"release number". This is easy to distinguish from "March 2010".
I'm sure that the Sage list will find this method "not right"
for a variety of reasons but I can tell you that there is no
perfect solution. The Axiom debate raged on for about a year.
Time-boxing isn't perfect but it allows big changes to
occur without breaking everyone and little changes to occur
without annoying everyone.
Every project seems to have this debate. Good luck with it.
Thanks for sharing the above.
1. How do you think your choice of releases and version numbers
impacted the number of Axiom users? Developers?
I have no way to track the number of users so I can't say.
Axiom forked (twice) and the forks have their own version numbering schemes,
each one different and neither one is clear, at least to me.
Developers will track whatever scheme you use and they won't like it :-)
It is very difficult to introduce large changes to the system if the
updates are too
frequent. I'm introducing a new package that includes over 50 new pieces of
algebra in this next release. The developer "silver" version has seen
each new
piece of algebra as it was introduced, with updates happening several
times a
day all month long but each new piece is useless standalone.
The "gold" version will have a fully implemented and tested piece so users
won't see the intermediate states.
At the rate you are currently releasing I don't know how you can introduce
fundamental changes like a reorganization of the categories. If there is
a mistake
the whole user community gets hit. And if it takes a couple weeks to
debug then
you'll have the world at your throat. The "silver" releases give your
developers
a chance to play before it goes out to the general public. I make NO
guarantees
about silver releases. They might not even build (although breaking the
build
is on my list of major sins).
If you "succeed" wildly then you'll have thousands of universities
downloading
versions, students will each have a different version depending on the
day of
the week they decided to download. A "gold" version would give professors
something concrete to point at.... e.g. the "September 2010" version.
2. Now that you've had the above version/release schedule for a few
years, is there anything you would change?
Well you'd be amazed at how quickly 8 weeks goes by....
The pace of 8 weeks between releases leaves 7 weeks of work and a week of
deep test, binary builds, etc. Fedora always seems to break things on every
release so it just takes a lot of time. I see you have the same breakage
happening
on certain platforms. It is very frustrating.
Having done the silver/gold release mechanism for about 4 years now I
think it is
"just about right". It gives lots of pressure to "hit the timebox" but
enough time
to plan for a major change.
Timeboxing also allows estimates of when to stop adding new features ("a
freeze")
and start cleaning up the little details. This subtle side-effect forces
fixing the little
annoying things that nobody notices but make it cleaner and more
professional.
3. How did your debate about the above end? Was their some definitive
argument, or?
Originally the development was released every 2 months with no public
repository
which made it hard to track changes. The debate ranged from "every day"
(for the
heavy developers who want to see everything) to "every 12 months" (for
those who
really didn't want to spend their life tracking a software tool). The
debate ended with
the "gold" 2 month timebox and the "silver" up-to-the-minute scheme. It
works well.
Curiously, the developers who wanted really frequent updates (and eventually
created their own forks) don't seem to have imposed any kind of schedule.
It is always easier to propose a schedule if you don't have to do the work.
The debate about "version numbers" was never settled to anyone's
satisfaction.
Since Axiom is timeboxed, the "Month Year" number is sufficiently unique.
Using git automatically versions the silver releases by SHA1 hash numbers.
People keep wanting to Godel-number the version numbers (I guess this is
git's scheme :-) ). They want to have major-minor-annoying-whocares-eh
kind of magic numbers. This leads to pointless debates about whether a
release is major or minor. Its an angels-on-the-head-of-a-pin debate.
I'm not able to say that something is a "major" release. That whole idea is
relative to the user's viewpoint. Open heart surgery isn't major if you're
the doctor but it is if you're the patient. I dropped the whole "numbers
are good" scheme and went with the "Month Year" scheme. The M/Y
"numbering" scheme has no semantics attached to it so there is no room
for debate.
I have seen this debate before and it can get very religious. Every project
seems to have the same debate. I'm not suggesting that Axiom's scheme
is the best idea for Sage but I thought you might find my experience
useful.
Tim Daly
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
