John Cremona wrote:
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
--
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
