On Wed, May 26, 2010 at 12:59 AM, David Kirkby <david.kir...@onetel.net> wrote: > Looking at the Sage roadmap > > http://trac.sagemath.org/sage_trac/roadmap > > I see Sage 4.4.3 is "A tiny minor release on the way to 5.0" which is > due on 30th May. > > Sage 5.0 is due out two days later on first of June. > > I don't believe such a release strategy says anything positive for > Sage. In fact, quite the opposite - I think it looks incredibly > amateurish. Who can take a program serious if two releases are made > two days apart?
Sage releases rarely come out on the random day that they happened to be scheduled for on trac. That day is just some field one fills in when making the milestone. I wouldn't take it too seriously. > It would not be as bad if Sage, like gcc and Python, had a couple of > branches, so those updating to 4.4.3 would know changes were minor, > whereas those updating to 5.0 expected big changes and accept big > risks. > > I know William has made several points before. > > 1) Linus Torvalds was at one point making daily releases. > > 2) iTunes are updated every couple of weeks > > 3) Sage will never have a release stratergry anything like > Mathematica. (For those that do not know, Wolfram Research issue a new > release with new features about every 18 months on average. Minor "bug > fix only" release might be made every 6 months or so on average) > > I'm still left wondering if Sage's release strategy needs a bit of a > minor adjustment (to put it mildly). > > I know I seem to be in a minority with Robert Bradsure on this, but I > still feel release numbers x.y.z should reflect the severity of the > changes. > > I sometimes wonder if trac tickets should have a "risk factor" > attached to them. Something like > > 1)- Very low risk (Typos, documentation errors, numerical noise on doctests.) > 2) Low risk. (Changes that occur on only one or two rarer operating > systems, or specific versions of specific Linux distributions). > 3) Medium risk (Changes to the library) > 4) High risk. (Updates of most standard packages) > 5) Very high risk (Updates to standard packages which are used by many > people on all systems (MPIR, MPFR, Python etc) or if a new standard > package is added to Sage. > > Release numbers would then reflect the type of changes occurring and > their associated risk. > > IMHO, it would be good if people obtain a version of Sage which has > only minor changes from a previous version and those changes are only > low risk bug fixes. Then they could be reasonably sure that asking > their system admin to install that version of Sage on a server would > unlikely to result in major headaches for 6 months or so. If you want to make a parallel stable version of Sage and release it that way, go for it. -- William -- 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
