Alex Ghitza wrote:
On Thu, 04 Feb 2010 09:10:25 +0000, "Dr. David Kirkby"
<david.kir...@onetel.net> wrote:
It seems to me that Sage version numbers follow the rule, that when last digit
in X.Y.Z get to 2, then Y is incremented. That is some logic I guess, but it is
not a sensible one. (I think this is a case of Mathematicians at work)
You are asking for it, so here it is: your argument is a case of
what mathematicians call "engineer's induction" -- claim appears to hold
in 2 or 3 cases, so it must be a universal truth :).
OK, but you get the point.
Silliness aside, I believe that even if the current numbering system is
not perfect, an effort is usually made to have the number illustrate the
magnitude of the changes.
Well, let us consider 4.3.1, which is the most recent release and smallest
possible change in version number (assuming X.Y.Z). William said of 4.3.1
"There were billions of tickets closed and bugs fixed."
http://groups.google.com/group/sage-devel/msg/6c42bcd951a9f526
Engineers would not use billions in this case:).
Hundreds of bugs fixed as a result of a
particularly succesful Bug Days would not get a new major version. It
used to be, until recently, that goals for the next release were
discussed on sage-devel. Trac milestones also usually have goals listed.
Well, I believe it was known before 4.3.1 was released, that the next release
would be 4.3.2.
[...]
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.
I'm pretty sure this was discussed at length fairly recently in the
context of having "stable" vs "bleeding edge" branches.
I don't recall that. I have however thought there should be two branches. I
don't however accept the view there are insufficient developers for this.
That is the approach GCC takes. If we look at the latest 4.4.3, we see
"This release is a bug-fix release, containing fixes for regressions in GCC
4.4.2 relative to previous releases of GCC."
http://gcc.gnu.org/gcc-4.4/
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.
Unfair comparisons. Both GCC and Mathematica are significantly older
and more mature than Sage. They can afford to be patient with new
functionality, see also below.
I know Sage existed in 2005. I don't know when the first release was. I think it
should be sufficiently mature by now to not have almost random version numbers.
I know Sage follows this "release early, release often" scheme, but I'm not
convinced this approach is really going to make Sage a viable alternative to to
Magma, Maple, Mathematica and Matlab.
I feel that the two main obstacles on Sage's path to its stated goal
are:
1. The (sometimes complete) lack of functionality in some areas of
mathematics
No doubt true.
I think there is a bias to number theory, which is understandable. But
ultimately, on a volunteer project, people are only going to work on things that
interest them.
2. The absence of a native Windows port.
Agreed. That is clearly a very significant obstacle. (Even as someone who has
worked primarily on porting to Solaris, I'm well aware a Windows port is needed
more than anything.)
It saddens me to admit to 2, since I think that Sage is awesome enough
that one could go through the trouble of using a virtual machine image
under Windows, or even (gasp!) give some flavour of Linux a try, but I
think it is nevertheless true.
Yes. I agree with your entirely on this.
Anyway, the point I'm trying to make here (and this goes in the
direction of Nick Alexander's post a few days ago), is that without
functionality, everything else seems pointless.
I semi-agree. If there was no functionality, then of course everything else
seems pointless. But with a source code of 250 MB or so, there is clearly a lot
of functionality already.
In the context of
stability: if a user upgrades Sage to a new version and this causes some
trouble in the form of new bugs, the said user might or might not be put
off.
There is a very important word there - *upgrades*.
They are very likely to be put off Sage if its the first time they have
downloaded Sage, then find it will not compile. Perhaps it's me, but the most
off-putting thing about downloading a program is finding it will not compile.
Upgrading one version to another and finding a new bug is of course annoying. If
I have a closed source program that is not programmable and it lacks the
functionality I want, then of course I will soon abandon it. But in the case of
open-source, which is programmable, I'd be less likely to dismiss it.
However, if a user needs to be able to accomplish a certain task
and Sage offers no way of doing so, or it's much worse at it than other
software, that person is very likely to not give Sage a try.
With 250 MB of source code, there is a lot of functionality. As such, any
changes are relatively small compared to the overall functionality.
Sage 4.0.0 - major new release. Sometime really great has happened. Be prepared
for some bugs (remember gcc 4.0.4 ?)
Sage 4.0.1 - only bug fixes
Sage 4.0.2 - only bug fixes
Sage 4.0.3 - only bug fixes
Sage 4.1.0 - semi- major release, new functionality.
Sage 4.1.1 - bug fixes only.
Sage 4.2.0 - new functionality.
Sage 4.2.1 - bug fixes only.
Developers would get their code reviewed, but know that if its contains new
functionality, it will have to wait until Z or Y is incremented before it will
get in.
You probably meant "wait until X or Y is incremented" (that's something
else engineers tend to have trouble with -- variable names :).
Yes, I did mean they would have wait until X or Y is incremented.
I have an objection to your last statement here: it is already hard
enough to get tickets that have new functionality reviewed and merged in
a timely fashion, and this results in bitrot and endless rebasing before
and throughout the review process. Suppose Sage 5.0.1 was just
released, then there could be a handful of releases until a new "major"
release comes around. I don't relish the thought of having to keep
rebasing my patches waiting for a review, and then most likely having to
keep rebasing my patches waiting for the merge -- in fact, I remember
Nicolas Thiery going half crazy at some point over the category
framework, and eventually sage-combinat got their own branch where they
can keep writing new code and periodically push things into the main
Sage branch. But this means that Nicolas is now (on a smaller scale)
release manager for sage-combinat.
I can see this, though if only minor fixes were made when changes were made in
Z, that should not be so severe. This issue is one of the big disadvantage of
Mercurial, in that you can't base your patches on what someone has already done,
as you don't know about that.
Getting back to the point, I believe it is too early in Sage's life to
tip the balance in the favour of increased stability *if it comes at the
cost of increasing the barrier to including new functionality*.
I've agreed with a lot of what you say, but I strongly disagree with that. A
review process comes at a cost of increasing functionality. Any sort of testing
comes at a cost of increasing functionality. But tons of functionality is not a
lot of use if its bug ridden.
There is always going to have to be some balance between adding functionality
and improving stability.
Someone else has made a similar point to me before, saying if he gets Sage put
on a server, he will not be able to request to the IT department they upgrade it
every few weeks. So a more tested, release is desirable some times.
Best,
Alex
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
