What about adopting a simpler strategy? What do you think about this: every 6 months (or 9, or 12 whatever), the developers are asked to focus on producing bugfixing instead of introducing new features. In this way, what happens is that one release every "n" months could be considered more stable and reliable, and these releases are kept on the website available for downloading together with the current release. In this way, I hope, there's really no overhead in the current work. Of course, some effort in changing goals twice a year would be required, so that old problems are solved.
Thanks for discussing this Regards Maurizio On 27 Ott, 17:54, William Stein <wst...@gmail.com> wrote: > On Tue, Oct 27, 2009 at 1:36 AM, Minh Nguyen <nguyenmi...@gmail.com> wrote: > > > Hi folks, > > > On Tue, Oct 27, 2009 at 5:22 AM, William Stein <wst...@gmail.com> wrote: > > >> Hi, > > >> I wonder why everybody (*) making suggestions has never put together a > >> single Sage release themselves, yet everybody who has done significant > >> work putting together Sage releases, organizing the web page, mirror > >> binaries, etc., has completely refrained from making any suggestions? > > > I have two excuses. > > > Lame excuse: I was busy preparing a draft of my Honours thesis. > > > Good excuse: I wanted to spend some time gathering my thoughts on the > > issue of maintaining a conservative series of releases. Here are my > > thoughts. > > > Let's imagine for the sake of discussion that we have two separate > > releases. On the one hand, there is a conservative double point > > release series like Sage 4.2.x which only have bug fixes and also bug > > fixes that have been back ported from major releases. Such bug fixes > > include fixing bugs in the Sage standard library, bug fixes in the > > Sage standard documentation, updating standard packages but not > > upgrading spkg's to upstream releases, etc. On the other hand, we have > > a major single dot release like Sage 4.x which includes new features > > in addition to bug fixes that have been back ported to the Sage 4.2.x > > series. Furthermore, both the double dot point and major releases are > > released more or less roughly at the same time. For something close to > > what I'm talking about, refer to the current situation with Python in > > which there is a maintenance release for Python 2.6.x, and at the same > > time there is a major release (i.e. Python 3.x) that includes new > > features and backward incompatible changes. > > I don't see the Python 2.x series as just a maintenance/bug fix > series. The difference between 3.x and 2.x is that 3.x made major > backward incompatible changes to 2.x. But 2.x still sees nontrivial > new development, packages, functionality, etc. > > An analogous project might be how the Linux kernel used to have a > stable and unstable version at the same time. In Linux development > they realized that entire approach was a huge mistake and got rid of > it. (Some people might not be old enough to remember this.) > > Another analogy might be PARI, which also has a stable and unstable > release. These evidently merge every 3-4 years or so, and I've been > told by many people (including the lead dev of pari) that it is a bad > idea to use the stable release, unless you have no choice. (He > repeatedly strongly recommend we switch to the unstable version for > Sage last time I visited him in Bordeaux.) > > Another analogous project would be Ubuntu, which has both say 9.10 > (any moment now), and 8.04.LTS. Probably the LTS releases of Ubuntu > are the most successful project I can think of right now as far as > stable/unstable goes. This is also nice because a Linux > distribution is more analogous to Sage than some of the other projects > above. > > 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 -~----------~----~----~----~------~----~------~--~---
