On Jan 16, 2012 1:45 AM, "Jeroen Demeyer" <[email protected]> wrote: > > I think it's time for me to talk about *development versions* of Sage > which are under construction and *not released* yet. With development > versions I mean beta's (which used to be called alpha's), rc's and > (trivially) stable versions.
Could you put a version of this email in /home/release? > There are 3 ways to determine the latest *released* development version: > * Look at the *sage-release* mailing list (or its archives). The > release of a development version will always be announced there: > http://groups.google.com/group/sage-release > * Look at the development version *download page*: > http://www.sagemath.org/download-latest.html > This can be accessed from the "Download/Development Release" menu on > http://www.sagemath.org/ > * Find the latest version without *README.FIRST* file in > http://boxen.math.washington.edu/home/release/ > > You can find the non-released versions also in > http://boxen.math.washington.edu/home/release/ > but they would always have a README.FIRST file. The main reason I put > them there is to be *open* about release management. Everybody can see > what I'm trying, which tickets I am merging. You can look at the file > *tickets.html* to see a list of tickets *successfully merged* in a Sage > release, for example > http://boxen.math.washington.edu/home/release/sage-5.0.beta1/tickets.html > "Successfully merged" means that all patches apply, Sage builds from > scratch, the documentation builds without warnings/errors, ptest and > ptestlong pass all tests, building an sdist and bdist works. Such > patches might still have known or unknown bugs on other systems, or bugs > not caught by doctesting. > > It's important to understand that the list of merged tickets *varies > often*. The sage-5.0.beta1 you download today will likely be different > from the sage-5.0.beta1 somebody else downloaded yesterday. Therefore, > it's *pointless to report bugs* for these versions (unless you track > down yourself what caused the bug). Also, sometimes I merge tickets > which have known bugs, for example to test the interaction with other > tickets or to test a possible fix. > > The next important question is: on which Sage version should I base my > patches, to what should I *rebase*? The most wrong answer is: the > latest stable Sage release (currently sage-4.7.2) because that might be > outdated. Using the *latest released* development version is good. > Even better would be to look at the latest non-released version, rebase > your patch to that but then: find out whether it *applies* to the most > recent released version. If not, find out with which patch it conflicts > and add that patch to the list of *dependencies* of the ticket. You > cannot expect reviewers to use a non-released version and (as said > before), non-released versions might change. > > Regarding this discussion, the *unofficial prealpha* releases that I > have been making recently should be treated like non-released versions. > The only difference is these prealphas are stable (won't change after > being announced). They might still contain non-reviewed tickets or even > known bugs. > > > Hope this clarifies some things, > Jeroen. > > -- > To post to this group, send an email to [email protected] > To unsubscribe from this group, send an email to [email protected] > For more options, visit this group at http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
