On Oct 24, 2009, at 7:10 PM, Jason Grout wrote: > mhampton wrote: > >> One thing that was mentioned on another thread is that the version >> number for sage-4.1.2 was quite misleading. It would help a lot if >> the version numbers were more grounded in reality. One simple change >> might be to not pick the version number until a final release has >> been >> decided on. Perhaps we could call the next release "sage-next" until >> it is finalized. > > +1
+1 from me too. There are two attitudes to big point upgrades--one is that they are a big motivation to upgrade and are relatively polished (certainly they make for good publicity), the other is that x.0 releases have lots of new code (and hence lots of new bugs) and should be avoided until the x.1 release comes. What view should we take? >> Another idea, but one that requires more effort, would be to have >> some >> sort of "LTS" release, for which only bugfixes would be applied. I >> don't want to personally volunteer to do that, but I think it would >> be >> great if someone else did :) > > If someone wanted to volunteer, then +1. However, this will probably > not realistically happen any time soon; Just disentangling bugfixes > from > feature enhancements will be a job, as often they are included in the > same patch. Sage development is still pretty rapid. I can see this > easily being a full-time job. What is meant by a conservative release? Is it one where nothing new went in? Even bugfixes can sometimes cause other bugs. It seems that two or three times a year a far-reaching, potentially destabilizing change goes through, e.g. the new notebook, symbolics, or coercion. Typically a huge volume of testing goes into these as well, but there's no test like the real world one of releasing. I agree that these releases should be clearly flagged as having lots of new features. We don't need to call them unstable, the conservative would naturally avoid them. Outside of these big changes, in my experience it seems that the bulk of bugs are either corner cases that remain undetected for a long time, or are bugs in functionality that was not present in previous releases. Making a release without new features wouldn't help either of these cases. I suppose spkg dependancy upgrades are another potentially destabilizing force, and there has already been talk about separating them from releases that only deal with the sage library (which are much easier to do distributed testing on from a technical standpoint) and those that touch stuff outside the library. Short of spkg changes (and the notebook and new symbolics could be seen as that) I think that very few release are regressions with respect to what their predecessor could do. It would also have to be done is such a way as to not hold up normal Sage development--long "bugfixes only" releases could stifle contributions. Also, short of concentrated periods like bug smashing events, I think its unrealistic for people to devote all the energy they have writing code used for their research or teaching to fixing bugs (though most people are more than willing to put some time into it as part of what they do "for the good of the community"). >> The easiest thing, which I hope can be implemented, is to highlight >> former releases that seem especially stable as Maurizio suggests. >> > > Somehow the wording needs to be picked to not say "the current release > is not stable; don't use it", but rather something like "major changes > were made in this release; you might find some corners that still need > polishing" I think it makes more sense to label the "stable" rather than the normal releases. I'm strongly -1 on having the conservative version as the default download, and making people go to extra work to get the latest. - 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 -~----------~----~----~----~------~----~------~--~---
