On May 26, 2010, at 5:06 PM, Tim Daly wrote:
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.
I'd like to have some kind of a rolling alpha, at least for the Sage
library, but one that is guaranteed to build and pass (almost?) all
tests (on some machine at least).
As for the version number, you're right, this can cause quite the
debate (and we've rehashed it here several times), but I don't think
we've seen your point of view before and I think it was very
informative. I think the biggest issue with our release numbers is
that they're decided before we decide what goes into them, and not so
easy to change after the fact--until that is resolved they will be
less useful than they otherwise could be. Having, e.g., a 5.0 goal to
push for is valuable (from a developers, management, and marketing
standpoint).
- Robert
--
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
