Do Sage version numbers follow any logic ?
Dr. David Kirkby
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)
Would it not be more appropriate to have some logic to the versions numbers,
which indicated the magnitude of the changes. It seems a mathematical formula is
applied to Sage version numbers, with version numbers indicating no measure of
the volume or type of changes made.
*Personally* I'd like to see changes in Z being *only* bug fixes and no new
functionality, but I don't think that would be a popular view. (William has told
me this before).
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.
If a list of bugs to be fixed in the X.Y.1 or X.Y.2 were published, a user could
consult that list, and determine if its worth the bother of him/her updating
Sage. They would determine if they are likely to be affected by them, and not,
they could put off upgrading until there was new functionality added when Y is
incremented.
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."
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.
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.
Personally I feel having something like
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.
Comments ?
Dave
Dr. David Kirkby
> Personally I feel having something like
>
> Sage 4.0.0 - major new release. Sometime really great has happened. Be
> prepared for some bugs (remember gcc 4.0.4 ?)
Sorry, that was supposed to be:
Sage 4.0.0 - major new release. Something really great has happened. Be
prepared for some bugs (remember gcc 4.0.0 ?)
Dave
ross k
> 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).
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. It would be ideal to do this and
have a numbering scheme like you have below (are these two ideas
compatible though?)
Ross
>
> I know Sage follows this "release early, release often" scheme, ...
> Personally I feel having something like
>
> 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.
>
> Comments ?
>
> Dave
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
Alex Ghitza
> 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 :).
Here are version numbers since 1.0:
sage-4.3.tar 260.62 MB 2009-12-24 17:45
sage-4.2.1.tar 258.56 MB 2009-11-14 18:26
sage-4.2.tar 259.19 MB 2009-10-25 06:08
sage-4.1.2.tar 256.41 MB 2009-10-15 01:44
sage-4.1.1.tar 210.48 MB 2009-09-14 07:00
sage-4.1.tar 207.49 MB 2009-07-09 22:16
sage-4.0.2.tar 205.27 MB 2009-06-19 12:46
sage-4.0.1.tar 202.43 MB 2009-06-06 17:16
sage-4.0.tar 204.43 MB 2009-05-31 11:15
sage-3.4.2.tar 206.14 MB 2009-05-12 05:14
sage-3.4.1.tar 208.44 MB 2009-04-22 04:31
sage-3.4.tar 204.55 MB 2009-03-12 05:13
sage-3.3.tar 213.85 MB 2009-02-21 18:50
sage-3.2.3.tar 205.98 MB 2009-01-06 07:09
sage-3.2.2.tar 205.64 MB 2008-12-30 20:24
sage-3.2.1.tar 204.74 MB 2008-12-20 06:28
sage-3.2.tar 203.55 MB 2008-11-20 21:02
sage-3.1.4.tar 202.27 MB 2008-10-20 15:12
sage-3.1.3.tar 202.34 MB 2008-10-14 16:50
sage-3.1.2.tar 196.46 MB 2008-09-20 03:03
sage-3.1.1.tar 190.52 MB 2008-08-17 18:42
sage-3.1.tar 190.51 MB 2008-08-17 03:00
sage-3.0.6.tar 189.49 MB 2008-07-31 03:15
sage-3.0.5.tar 188.25 MB 2008-07-11 18:55
sage-3.0.4.tar 188.22 MB 2008-07-10 08:46
sage-3.0.3.tar 190.18 MB 2008-06-23 18:00
sage-3.0.2.tar 189.86 MB 2008-05-24 23:36
sage-3.0.1.tar 211.71 MB 2008-05-05 13:13
sage-3.0.tar 208.27 MB 2008-04-24 02:49
sage-2.11.tar 195.47 MB 2008-03-31 03:29
sage-2.10.4.tar 189.80 MB 2008-03-18 00:35
sage-2.10.3.tar 184.12 MB 2008-03-11 20:21
sage-2.10.2.tar 209.34 MB 2008-02-23 02:47
sage-2.10.1.tar 205.03 MB 2008-02-03 01:54
sage-2.10.tar 200.56 MB 2008-01-18 23:27
sage-2.9.3.tar 195.65 MB 2008-01-06 08:01
sage-2.9.2.tar 197.76 MB 2008-01-05 14:38
sage-2.9.1.1.tar 196.25 MB 2007-12-25 22:36
sage-2.9.1.tar 201.66 MB 2007-12-24 20:09
sage-2.9.tar 185.48 MB 2007-12-16 15:32
sage-2.8.15.tar 167.35 MB 2007-12-04 07:21
sage-2.8.14.tar 164.90 MB 2007-11-25 07:59
sage-2.8.13.tar 164.87 MB 2007-11-21 21:56
sage-2.8.12.tar 163.28 MB 2007-11-07 15:34
sage-2.8.11.tar 158.24 MB 2007-11-03 00:41
sage-2.8.10.tar 157.32 MB 2007-10-29 04:31
sage-2.8.9.tar 156.71 MB 2007-10-25 08:01
sage-2.8.8.1.tar 156.08 MB 2007-10-21 17:15
sage-2.8.7.2.tar 153.20 MB 2007-10-20 17:44
sage-2.8.7.tar 153.26 MB 2007-10-16 06:05
sage-2.8.6.tar 151.41 MB 2007-10-06 07:25
sage-2.8.5.1.tar 148.39 MB 2007-09-26 16:38
sage-2.8.5.tar 148.40 MB 2007-09-21 08:12
sage-2.8.4.2.1.tar 147.02 MB 2007-09-20 17:01
sage-2.8.4.2.tar 146.40 MB 2007-09-13 21:41
sage-2.8.4.1.tar 145.79 MB 2007-09-09 18:52
sage-2.8.4.tar 145.78 MB 2007-09-07 22:18
sage-2.8.3.6.tar 144.96 MB 2007-09-06 09:33
sage-2.8.3.5.tar 144.91 MB 2007-09-06 01:03
sage-2.8.3.tar 141.80 MB 2007-08-31 15:35
sage-2.8.2.tar 133.31 MB 2007-08-22 17:44
sage-2.8.tar 137.38 MB 2007-08-13 01:18
sage-2.7.3.tar 135.73 MB 2007-08-03 03:05
sage-2.7.2.tar 135.30 MB 2007-07-29 04:19
sage-2.7.1.tar 129.62 MB 2007-07-24 23:44
sage-2.7.tar 114.79 MB 2007-07-20 05:09
sage-2.6.tar 101.22 MB 2007-06-03 05:32
sage-2.5.3.tar 97.91 MB 2007-05-23 01:38
sage-2.5.2.tar 98.24 MB 2007-05-20 17:15
sage-2.5.1.tar 97.52 MB 2007-05-19 17:11
sage-2.5.0.2.tar 96.62 MB 2007-05-11 16:55
sage-2.5.0.1.tar 96.61 MB 2007-05-11 05:56
sage-2.5.tar 96.57 MB 2007-05-09 02:06
sage-2.4.2.tar 92.46 MB 2007-04-13 06:52
sage-2.4.1.2.tar 92.03 MB 2007-03-28 20:25
sage-2.4.1.1.tar 91.88 MB 2007-03-28 05:37
sage-2.4.1.tar 91.88 MB 2007-03-28 02:40
sage-2.4.tar 91.69 MB 2007-03-26 02:34
sage-2.3.tar 88.31 MB 2007-03-06 20:38
sage-2.2.tar 87.19 MB 2007-03-01 01:29
sage-2.1.4.tar 86.89 MB 2007-02-18 06:41
sage-2.1.3.1.tar 85.80 MB 2007-02-17 10:01
sage-2.1.3.tar 85.62 MB 2007-02-16 17:44
sage-2.1.2.tar 85.62 MB 2007-02-16 07:25
sage-2.1.0.1.tar 85.45 MB 2007-02-09 17:05
sage-2.1.tar 85.70 MB 2007-02-09 09:54
sage-2.0.tar 83.96 MB 2007-01-28 14:33
sage-1.9.tar 83.99 MB 2007-01-27 17:54
sage-1.8.2.1.tar 83.38 MB 2007-01-25 05:27
sage-1.8.2.tar 83.38 MB 2007-01-25 04:19
sage-1.8.1.tar 82.84 MB 2007-01-24 05:55
sage-1.8.tar 82.78 MB 2007-01-23 16:55
sage-1.7.1.tar 80.99 MB 2007-01-18 09:42
sage-1.7.tar 81.12 MB 2007-01-16 08:54
sage-1.6.1.tar 77.53 MB 2007-01-14 10:45
sage-1.6.tar 74.30 MB 2007-01-12 15:11
sage-1.5.3.tar 73.74 MB 2007-01-05 19:58
sage-1.5.2.tar 72.01 MB 2007-01-05 00:06
sage-1.5.1.2.tar 72.75 MB 2006-12-16 23:47
sage-1.5.1.1.tar 72.75 MB 2006-12-16 17:57
sage-1.5.1.tar 72.75 MB 2006-12-16 07:31
sage-1.5.0.2.tar 72.72 MB 2006-12-15 06:51
sage-1.4.1.2.tar 64.19 MB 2006-10-19 19:09
sage-1.4.1.1.tar 64.18 MB 2006-10-19 04:36
sage-1.4.1.tar 64.18 MB 2006-10-19 00:42
sage-1.4.tar 63.38 MB 2006-10-06 06:45
sage-1.3.7.3.3.tar 61.45 MB 2006-09-22 01:54
sage-1.3.7.3.2.tar 58.65 MB 2006-09-22 00:57
sage-1.3.7.3.tar 56.45 MB 2006-09-21 11:52
sage-1.3.7.2.tar 60.77 MB 2006-09-12 18:17
sage-1.3.7.1.tar 60.05 MB 2006-09-11 04:58
sage-1.3.7.tar 54.52 MB 2006-09-09 06:48
sage-1.3.6.4.tar 52.55 MB 2006-08-31 20:03
sage-1.3.6.3.tar 51.71 MB 2006-08-13 18:50
sage-1.3.6.2.tar 51.45 MB 2006-08-07 17:15
sage-1.3.6.1.tar 51.31 MB 2006-08-04 09:30
sage-1.3.6.tar 51.30 MB 2006-07-30 12:58
sage-1.3.5.7.tar 51.26 MB 2006-07-28 18:54
sage-1.3.5.6.tar 52.24 MB 2006-07-28 09:30
sage-1.3.5.5.tar 52.12 MB 2006-07-26 03:15
sage-1.3.5.4.tar 50.69 MB 2006-07-21 14:48
sage-1.3.5.3.tar 54.92 MB 2006-07-15 14:21
sage-1.3.5.2.tar 50.27 MB 2006-07-08 15:25
sage-1.3.5.1.tar 49.91 MB 2006-07-05 04:26
sage-1.3.5.tar 49.57 MB 2006-07-04 03:29
sage-1.3.4.2.tar 48.69 MB 2006-06-27 08:41
sage-1.3.4.1.tar 48.69 MB 2006-06-26 20:14
sage-1.3.4.1.0.tar 48.68 MB 2006-06-26 20:08
sage-1.3.4.tar 48.66 MB 2006-06-25 19:14
sage-1.3.3.7.tar 48.67 MB 2006-06-20 19:23
sage-1.3.3.6.tar 48.66 MB 2006-06-19 01:20
sage-1.3.3.5.tar 48.66 MB 2006-06-18 06:58
sage-1.3.3.4.tar 48.65 MB 2006-06-16 07:24
sage-1.3.3.3.tar 48.78 MB 2006-06-12 18:28
sage-1.3.3.2.tar 48.78 MB 2006-06-12 02:26
sage-1.3.3.1.tar 48.78 MB 2006-06-08 22:30
sage-1.3.3.tar 48.54 MB 2006-06-07 02:05
sage-1.3.2.2.tar 48.97 MB 2006-05-28 01:21
sage-1.3.2.1.tar 48.98 MB 2006-05-25 21:22
sage-1.3.2.tar 49.26 MB 2006-05-23 02:05
sage-1.3.1.3.tar 47.87 MB 2006-05-23 02:04
sage-1.3.1.2.tar 48.95 MB 2006-05-19 21:21
sage-1.3.1.1.tar 48.95 MB 2006-05-18 19:04
sage-1.3.1.tar 48.95 MB 2006-05-17 07:17
sage-1.3.0.1.tar 48.92 MB 2006-05-11 22:07
sage-1.3.0.tar 48.92 MB 2006-05-08 20:14
sage-1.2.5.tar 48.74 MB 2006-05-05 07:38
sage-1.2.4.tar 48.63 MB 2006-05-02 10:45
sage-1.2.3.1.tar 48.50 MB 2006-04-22 01:19
sage-1.2.3.tar 48.50 MB 2006-04-21 03:55
sage-1.2.2.tar 48.71 MB 2006-04-18 06:39
sage-1.2.1.tar 50.90 MB 2006-04-14 01:20
sage-1.2.0.tar 46.96 MB 2006-04-07 20:22
sage-1.1.2.tar 42.04 MB 2006-03-15 08:45
sage-1.1.1.tar 42.02 MB 2006-03-13 10:55
sage-1.1.0.tar 42.02 MB 2006-03-10 02:11
sage-1.0.9.tar 42.00 MB 2006-03-07 19:45
sage-1.0.8.tar 42.00 MB 2006-03-07 06:53
sage-1.0.7.tar 39.88 MB 2006-03-03 12:15
sage-1.0.6.tar 39.93 MB 2006-02-26 16:18
sage-1.0.5.tar 39.87 MB 2006-02-21 10:15
sage-1.0.4.tar 39.73 MB 2006-02-17 10:28
sage-1.0.3.tar 39.69 MB 2006-02-13 16:06
sage-1.0.2.tar 39.69 MB 2006-02-13 01:01
sage-1.0.1.tar 39.80 MB 2006-02-10 11:28
sage-1.0.0.1.tar 39.27 MB 2006-02-05 15:47
sage-1.0.0.tar 39.26 MB 2006-02-04 08:50
You will notice plenty of counterexamples to the guessed "rule",
e.g. 2.8.15.
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. 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.
> [...]
>
> 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.
> If a list of bugs to be fixed in the X.Y.1 or X.Y.2 were published, a user could
> consult that list, and determine if its worth the bother of him/her updating
> Sage. They would determine if they are likely to be affected by them, and not,
> they could put off upgrading until there was new functionality added when Y is
> incremented.
There are release notes for all releases, with a complete list of closed
tickets. The user can consult the list and see (a) what annoying bugs
have been fixed and (b) what new functionality was added; this is a good
base for making a decision about upgrading or waiting, I think.
> 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 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
2. The absence of a native Windows port.
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.
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. 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. 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.
> 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 :).
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.
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*.
Best,
Alex
--
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
-- Australia -- http://www.ms.unimelb.edu.au/~aghitza/
Dr. David Kirkby
> On Thu, 04 Feb 2010 09:10:25 +0000, "Dr. David Kirkby" <david....@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
Dr. David Kirkby
> 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
William Stein
> 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.
>
As long as I'm involved, Sage is not ever going to have a release
cycle anything like Mathematica. Your wasting your time suggesting
that.
> 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.
Seriously, can anybody really see Sage ever getting taken up by "a lot
of commercial companies" unless there is a support company in place
like one has with RedHat, Novell, etc.? When there is a company
standing behind supporting Sage, with paying customers, paid
employees, and support contracts, then that company can have releases
like you describe if that is actually what those paying customers
want.
William
Dr. David Kirkby
> 2010/2/4 Dr. David Kirkby <david....@onetel.net>:
>> 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.
>>
>
> As long as I'm involved, Sage is not ever going to have a release
> cycle anything like Mathematica. Your wasting your time suggesting
> that.
I thought I made it clear I was not suggesting that, when I said:
"though I'm not suggesting a major release is made on average every theee years,
which is what Mathematica have done"
>> 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.
>
> Seriously, can anybody really see Sage ever getting taken up by "a lot
> of commercial companies" unless there is a support company in place
> like one has with RedHat, Novell, etc.? When there is a company
> standing behind supporting Sage, with paying customers, paid
> employees, and support contracts, then that company can have releases
> like you describe if that is actually what those paying customers
> want.
With the very high cost of Mathematica, then I think Sage has a chance of being
used more in commercial companies. Then people will support it on a commercial
basis, like they do with Apache and Wireshark - two other open-source projects.
But even in a university environment, some people want something that does not
change as often. I'm not the first to make this point, and I doubt I'd be the
last. Perhaps asking on sage-support might have given a different view, as that
would more likely to reach users who are not developers.
Anyway, I'm probably wasting my time, so I will not bother.
Dave
kcrisman
> But even in a university environment, some people want something that does not
> change as often. I'm not the first to make this point, and I doubt I'd be the
> last. Perhaps asking on sage-support might have given a different view, as that
> would more likely to reach users who are not developers.
I'm not even sure about this argument, though. Being able to upgrade
quickly, regardless of version number, in order to get new
functionality (such as .rref() ) is also very valuable in the
educational environment, at least at institutions that have no choice
but Sage for a comprehensive system.
But also from the developer perspective, I think that the "endless
rebasing" argument is very important, given that it is a volunteer
project, but one with a fairly large number of developers (I assume?)
for one that doesn't always have well-defined "modules" that will be
touched by a few developers each. And one with developers whose day
job is usually not directly related to programming!
- kcrisman
ross k
(It sounded like you were a bit discouraged and I hope this doesnt
sound condescending but...)
You were right to query - I believe we should always think it is
legitimate to query how we might be able to do things be better.
But now that we've had that discussion and its seems like things will
stay the same I want to suggest that right now this issue is far
overshadowed by so many other more important ones. Having being
surrounded by Matlab (and to a lesser extent Mathematica and Maple)
for about 15 years in a corporate environment, I have to admit am in
awe of the energy and rate of development of Sage since 2005. (Note -
Im comparing 15 years of the "commercials" development to 5 years of
Sage's)
I recently attended an in-house promotion of the latest "major"
release of Matlab and I cant tell you how underwhelmed I was over a
release that justified a major increment of their version number.
After mentally distilling their presentation to the bare bones, I
surmised that basically their "major" release had some very minor
improvements in functionality and some minor improvements in the GUI.
So version numbers are often a marketing tool.
One of the main issues is the choice Sage made for its development
model. At first, it looked like the model represented the "building of
a Frankenstein" but on closer examination its more like we're
"collecting jewels" (the "best of breed" of open source that has the
right amount of functionality, often years of development into
precision specialist software, that wont take long to integrate and
looks like it has potential for us to develop it further).
Another cool point is: whatever success these jewels had outside of
Sage, now they have access to to all of Sages community for
development, documentation, bug finding and fixing (as Sage is
similarly and symbiotically connected to the Python community for the
development etc of some existing and future libraries)
So Sage will continue having these packages being integrated into it
(either by developers so they can participate in something big or
found by the Sage community) so theres no way commercial software can
keep up (regardless if they are ahead in market share at the moment -
"No-one every got fired for buying IBM" once apon a time but were are
they now?)
Forget "Viable alternative", the reason why I feel these commercial
products should be shuddering in their boots is because of this
amazing and rare development model.
best
Ross
Dr. David Kirkby
> David
>
> (It sounded like you were a bit discouraged and I hope this doesnt
> sound condescending but...)
No. I realise I am in a minority among Sage developers. I suspect my views might
be a bit less of a minority on sage-support. But even there, I expect they will.
> You were right to query - I believe we should always think it is
> legitimate to query how we might be able to do things be better.
Yes.
> But now that we've had that discussion and its seems like things will
> stay the same I want to suggest that right now this issue is far
> overshadowed by so many other more important ones. Having being
> surrounded by Matlab (and to a lesser extent Mathematica and Maple)
> for about 15 years in a corporate environment, I have to admit am in
> awe of the energy and rate of development of Sage since 2005. (Note -
> Im comparing 15 years of the "commercials" development to 5 years of
> Sage's)
>
> I recently attended an in-house promotion of the latest "major"
> release of Matlab and I cant tell you how underwhelmed I was over a
> release that justified a major increment of their version number.
> After mentally distilling their presentation to the bare bones, I
> surmised that basically their "major" release had some very minor
> improvements in functionality and some minor improvements in the GUI.
> So version numbers are often a marketing tool.
Yes, version numbers can be a marketing tool. In fact, I do know of companies
that will purchase major updates, but not minor ones. So by making the version
number increment more, they get more sales.
It was clear there was a massive jump in functionality between Mathematica 5.2
and 6. The changes to 7 have been far less drastic, and perhaps a 6.1 would have
been more normal.
> One of the main issues is the choice Sage made for its development
> model. At first, it looked like the model represented the "building of
> a Frankenstein" but on closer examination its more like we're
> "collecting jewels" (the "best of breed" of open source that has the
> right amount of functionality, often years of development into
> precision specialist software, that wont take long to integrate and
> looks like it has potential for us to develop it further).
> Another cool point is: whatever success these jewels had outside of
> Sage, now they have access to to all of Sages community for
> development, documentation, bug finding and fixing (as Sage is
> similarly and symbiotically connected to the Python community for the
> development etc of some existing and future libraries)
>
> So Sage will continue having these packages being integrated into it
> (either by developers so they can participate in something big or
> found by the Sage community) so theres no way commercial software can
> keep up (regardless if they are ahead in market share at the moment -
> "No-one every got fired for buying IBM" once apon a time but were are
> they now?)
>
> Forget "Viable alternative",
Well, that is a stated mission.
> the reason why I feel these commercial
> products should be shuddering in their boots is because of this
> amazing and rare development model.
I'm not sure they are shuddering in their boots, but I think it is pretty clear
Wolfram Research see Sage as a threat.
I know there was this discussion before about the sponsored Google ads when one
search for Sage math. Personally I'm pretty convinced Wolfram Research have
decided to target Sage and pay for Google ads, though I know there are those
that argue that is not the case. (There's no need to discuss this one agan).
Dave
Harald Schilly
> I recently attended an in-house promotion of the latest "major"
That sounds extremely boring. I think matlab's success is that they
started very early and listened closely what the users needed -
something to manipulate matrices easily, not directly the lapack&co.
stuff. Also, universities and industry had money to finance them and
collaborative software development across the world wasn't possible -
it's now easy because the internet has gotten so fast and there are
good tools for that. In the meantime, matlab was just consistent to
their wrong design decisions and subtle "differences" to other
systems. That's why it will still stick around for a long time ...
> At first, it looked like the model represented the "building of
> a Frankenstein" but on closer examination its more like we're
> "collecting jewels"...
That's a good picture, thanks! I have the feeling I'll reuse that
phrase somewhere -> sage-marketing ;)
> Another cool point is: whatever success these jewels had outside of
> Sage, now they have access to to all of Sages community for
> development, documentation, bug finding and fixing ...
Sage acts like a catalyst in chemistry. It widens the audience of
small software packages (although indirectly) and those who are
interested why sage can do this and that or want to improve something,
they find out about them and get engaged with the specific communities
or just via a simple upstream bug report. It's a linear relationship
between the number of downloads ~ number of users ~ number of
developers.
...and to come back on topic: looking back, i think the best version
number for Sage were the release dates (back in the early 0.x time).
Today, a "YYYY-MM" string would be nice (adding a .1 if there is a
second release in the same month).
H
Dr. David Kirkby
> ...and to come back on topic: looking back, i think the best version
> number for Sage were the release dates (back in the early 0.x time).
> Today, a "YYYY-MM" string would be nice (adding a .1 if there is a
> second release in the same month).
>
> H
I can't say I agree with that.
Even though the Y.Z numbers of X.Y.Z don't seem to mean a lot, I assume if X was
updated, it would be believed there were significant changes. With a date, one
knows very little indeed about the amount of change. (Of course, you know more
about the date).
Rather than add a .1 if there was two releases in the same month, would it not
be simpler to just have the release date in full? But I still think the current
numbering is better than a date, even though I have my concerns about the
current numbering method.
Dave
John Cremona
Except very occasionally a release is followed by a quick emergency
bug fix. And also rather occasionally there is a huge new feature.
Thus I would expect that
* most releases sage-x.y.z would increment y and reset z (to 0, or 1).
* small quick emergency bugfix releases would just increment z
* really major releases (e.g. 100% doctests! or the Windows port!)
would increment x (and reset y and z to 0, or 1).
This is close to what we do except that z is incremented when it
perhaps ought to have been y. For example, 4.3.2 should perhaps have
been 4.4, while 5.*.* is waiting for a really big milestone (which we
should perhaps decide on in advance, as a big but achievable target).
For a start, please let's decide on what's to come next after 4.3.2.
Today I checked in a patch (including a bugfixed spkg) and had to mark
it 4.3.2 since there was nothing else! Of course it should not go
into 4.3.2 since that's now at rc0, hence on feature-freeze.
John
Dr. David Kirkby
> Surely almost all Sage releases contain major new functionality!
That's true.
Personally I think an occasional bug-fix-only release would be useful. Where a
release is planned to be a bug fix only. Even if they are very occasional, like
every 6 months.
Those 6-monthly bug-fix only releases would give something for someone to
install on a server where they don't intend updating it every month.
Minh made a 4.3.0.1 release recently, which just had the one patch needed for
Solaris. That was very useful. (4.3.1 has already been released at this point,
which is why a 4th digit was added).
> Except very occasionally a release is followed by a quick emergency
> bug fix. And also rather occasionally there is a huge new feature.
> Thus I would expect that
>
> * most releases sage-x.y.z would increment y and reset z (to 0, or 1).
I'm not sure why you would reset z to 1 on most releases. I would reset it to 0.
> * small quick emergency bugfix releases would just increment z
Yes, that sounds logical, though perhaps a 4th digit (like 4.3.0.1) should be
used for quick emergency bug fixes, whereas incrementing z would be used for
*planned* bug-fix only releases - perhaps one every 6 months. That should not
annoy too many people, but would give an extra-stable release for those that
want it.
> * really major releases (e.g. 100% doctests! or the Windows port!)
> would increment x (and reset y and z to 0, or 1).
I would have thought increment x as you say, but reset y and z to 0. So the
Windows port becomes 5.0.0.
But I like your basic strategy. I think it is better than the current one, which
appears to lack any sensible logic to me.
> This is close to what we do except that z is incremented when it
> perhaps ought to have been y. For example, 4.3.2 should perhaps have
> been 4.4,
Agreed. It is more than just a bug fix.
Perhaps the after 4.3.2, we go to 4.5.0, then only change the last digit for
bug-fixes, which means after 4.5, the next one should be planned to be 4.6,
rather than 4.6.1, which is what I expect it will be, unless a new strategy is
used.
> while 5.*.* is waiting for a really big milestone (which we
> should perhaps decide on in advance, as a big but achievable target).
Yes, that makes sense.
> For a start, please let's decide on what's to come next after 4.3.2.
> Today I checked in a patch (including a bugfixed spkg) and had to mark
> it 4.3.2 since there was nothing else! Of course it should not go
> into 4.3.2 since that's now at rc0, hence on feature-freeze.
In theory, release candidates are feature freezes, but in practice that is not
always the case. Significant new features are going into releases candidates.
Overall John, you and I see to be on a very similar wavelength.
> John
Dave
Robert Bradshaw
- For a major new feature, or if a year has passed, update x.
- If we know of a significant feature that's going to be merged in
ahead of time, update y.
- Otherwise, update z.
- Bugfix only, release x.y.z.w.
Anyone is welcome to release/maintain a bugfix only Sage at any time,
but unless its critical the people who actually do release managements
decide putting out new features is a better use of their time. There
are pros and cons to the "release early, release often" way of doing
things, but this has been discussed on this thread and many others,
and I don't see our frequency or content of releases changing unless
the (volunteer) developer and release community changes.
I agree that there's lots of room for improvement in deciding whether
x or y should be updated, but the difficulty (both socially and
technically) is that a release is usually named before it is decided
what to put into it.
- Robert
Nick Alexander
On 4-Feb-10, at 1:34 PM, Minh Nguyen wrote:
> Hi David,
>
> On Thu, Feb 4, 2010 at 8:10 PM, Dr. David Kirkby
> <david....@onetel.net> wrote:
>
> <SNIP>
>
>> Comments ?
>
> In the past [1] I expressed an interest in maintaining a "conservative
> release". That was before I realized that release management is a
> full-time job. Looking back, it's really is a full-time job. Perhaps
> not to other people. But I guess due to my limited experience and
> average intelligence, release management often consumes me full-time.
When I managed a release (with Craig!) it took both of us full-time to
coordinate one release.
Nick
Alex Ghitza
> In the past [1] I expressed an interest in maintaining a "conservative
> release". That was before I realized that release management is a
> full-time job. Looking back, it's really is a full-time job. Perhaps
> not to other people. But I guess due to my limited experience and
> average intelligence, release management often consumes me full-time.
That's really overly modest of you. I don't know anyone who has done
Sage release management and not found it to be very time-consuming.
I'm happy you wrote this though, because I had an issue with the
following view expressed earlier in this thread...
David wrote:
> 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.
...but I thought it would be inappropriate for me to reply to it since
I have never done release management work myself.
> I don't know if I would be around in the future to contribute
> anything. So during my time with the Sage community, I have
> endeavoured to document as much as possible many issues relating to
> Sage development: managing a release, doctesting the Sage library,
> source code management, coding conventions, docstring conventions, how
> to get involved in the Sage community, etc. By doing so, when I'm no
> longer active in the Sage community, documentation relevant to aspects
> of Sage development would still be around and not buried in the
> mailing list archives.
Well, I hope you *will* be around in the future, whether in the current
high-time-commitment mode or on a more occasional basis. But thanks for
putting in the effort of documenting these things; "bus factor" is an
issue that has been raised among Sage devels before, and your work is a
great contribution to attenuating it.