On Wed, May 26, 2010 at 5:06 PM, Tim Daly <d...@axiom-developer.org> 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
Just a remark -- we do not release as frequently as you think. There have been
10 releases in the last 6 months.
> 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,
I think we have around 8000 downloads per month, last time I checked.
> 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.
Yes, Fedora is indeed annoying that way.
>
> 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
I really appreciate you taking the time to write the above email and share your
experiences. Thanks!
The debate is happening right now, but I don't see this going to
religious proportions. The fact is, we're using the major-minor
versioning scheme, and we'll be sticking to that for the foreseeable
future. But it is useful to hear people's experiences and
concerns. I think this discussion is very healthy.
-- William
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
--
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
