I hope it's obvious that in my suggested plan, it would be rare for the number to change between alpha & rc, as this would happen only if something major was deemed ready, like the recent notebook rewrite.
John 2009/10/26 mhampton <hampto...@gmail.com>: > > Yes, I think doing all those things would help a lot. John Cremona's > versioning plan seems to be the best compromise between convenience > and accuracy, and doesn't seem like it would cause big problems. And > adding an unmirrored link to the previous versions would be great for > a number of reasons - hopefully this would be relatively easy to do. > > Having something like no spkg upgrades or other major revisions as a > guideline for double point releases would help too. Maybe it would be > not too much extra work to schedule such a release once a year? It > could happen unplanned more than that, but it could be a good prelude > to a release with more changes. Such a minimal release should be > easier than most, so ideally it could happen quite quickly. > > -Marshall > > On Oct 26, 12:25 pm, Robert Bradshaw <rober...@math.washington.edu> > wrote: >> 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 -~----------~----~----~----~------~----~------~--~---
