On Oct 26, 2009, at 7:04 AM, Dr. David Kirkby wrote: > Why not 'beta' like most other projects? If something goes wrong, > then one might > have a beta2. I've never come across any other open-source project > which adds > 'next'.
We essentially do have betas, we just don't call them such. Usually the sequence goes alpha -> beta -> release candidate -> release. I'm not sure why, but historically we have been jumping directly from alpha to release candidate. On Oct 26, 2009, at 7:58 AM, John Cremona wrote: > Would it not be a lot simpler if we did what we do now, except that if > during the sequence of alpha-releases it becomes apparent that the > "next" release is going to have some significant change which warrants > a different number from that of the alpha versions (e.g. 4.1.2.alpha? > should have been called 4.2.alpha?) then this change could be made at > the point when alpha? becomes rc? (which surely means the same as > beta? anyway), since that's when there is a freeze on new features. > > As long as there is a log somewhere explaining how 4.1.2.alpha? > matured into 4.2 instead of 4.1.2 (or whatever the numbers are next > time this happens) then this would seem to keep everyone happy. I think this is a great way to handle it. There seem to be two topics under discussion here: version numbering and conservative releases. Right now version numbering is fairly arbitrary--it seems we choose a number and then stick whatever is ready into it. When a year rolls around, we issue a major point upgrade just because. This means picking out release as stable or not is hard to do (especially for the "non-developer, non-bleeding-edge" crowd). Would it be enough if we had some standard like no .spkg upgrades and or other major revisions in x.y.z releases? I think this alone could help a lot. Also, perhaps we could put a "previous versions" on the main page next to/under the "download binary - source - components" link. We wouldn't have to mirror them. I used to like how it was so easy to get to a list of all releases (at least the source ones). - Robert --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
