ross k wrote:
I know this subject is a contentious one so Ill just make a quick comment...
It would however mean that people that wanted a stable release to install on
a server they can't change every couple of weeks, would chose an X.Y.1, or
an X.Y.2, safe in the knowledge that it should be quite stable, as only bug
fixes were applied.
. . .
Wolfram Research do that too, with their X.Y.Z. A major release was
Mathematica 6. Only bug fixes were applied in 6.0.1 - there was no new
functionality.
Thats how I was deciding to upgrade a few months ago and I guess a
number of people and companies think of versioning like this
(including as you said Mathematica etc).
It is a pretty standard way in software development. But with billions of
tickets merged into 4.3.1 (William's words)
http://groups.google.com/group/sage-devel/msg/6c42bcd951a9f526
basing your decision on a Sage version number would not be very useful.
I believe Sage is sufficiently mature that is should start being a bit more like
Mathematica, though I'm not suggesting a major release is made on average every
theee years, which is what Mathematica have done. I think its been going 20
years, and is still only at version 7.
The only thing is theres a big advantage in introducing new
functionality in Sage as soon as its available. Doing that, you
maximize the time that its exposed to the user base and consequently
minimise the time it might be buggy.
True, but it does come at *very* significant risks too. Not every user wants to
be a beta tester. Some want a stable version of the software.
I can't see there being a lot of take up of Sage in commercial companies when
the latest stable release is changing every month or so. I believe a more
conservative approach is needed, whilst still making frequent releases for those
that want to be at the bleeding edge.
It would be ideal to do this and
have a numbering scheme like you have below (are these two ideas
compatible though?)
Projects like gcc do this, by making daily or perhaps weekly snapshots available
for those that want to try the latest code, and accept the risks of doing this.
I'm not convinced that is very practical with Mercurial. Perhaps I am mistaken
though as I don't know much about Mercurial.
Dave
--
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
