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.
Tim Daly
kcrisman wrote:
On May 26, 3:56 pm, William Stein <wst...@gmail.com> wrote:
On Wed, May 26, 2010 at 12:50 PM, Dr. David Kirkby
<david.kir...@onetel.net> wrote:
On 05/26/10 05:34 PM, leif wrote:
On 26 Mai, 18:09, Robert Bradshaw<rober...@math.washington.edu>
I like the risk assessment field idea.
Me too, perhaps give it a different name.
What would you call it? There are at least three things to consider I can
think of.
1) What are the risks associated with a change?
2) The probability of the change causing a problem.
3) The impact such a problem would cause.
There might be others.
Even things that have a fairly high probability of causing a problem are
probably not worth worrying about too much if the impact would be minimal.
Conversely, even something which has a low probability of causing a problem,
but would have major consequences, needs to be taken seriously.
However, unless there was a *major* change in Sage release practices, it
would be a bit pointless doing any sort of risk analysis. I don't detect
much of an appetite for a major change in Sage release practices. In fact, I
detect quite the converse.
At a bare minimum, any major change should be designed by people who
have actually done some Sage releases.
Wouldn't it be easiest for someone to change the 5.0 release date
thingie on Trac to "sometime in June, but may be pushed to July or
later in order to fulfill goals (Cygwin, etc.)"? This seems like even
more of a tempest in a teapot than the SPKG.txt thread ;)
- kcrisman
--
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
