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? 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. 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
