On Mar 6, 12:31 pm, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> On 2012-03-06 12:12, Keshav Kini wrote:
>
> > I don't understand why you need to do this. The merge process should be
> > a one-time thing, right? Isn't that what the merger script is for?
> > Doesn't "preparing a release" basically mean finalizing the list of
> > patches that will go into the release, not actually making any commits
> > or putting together any tarballs?
>
> No, "preparing a release" == "while (!finished) {decide on a list of
> patches that will go into the release, actually make the commits and put
> together the tarballs, test the tarballs on the buildbot}".Of course, and you can play with the merger script / [newly] included tickets as you like and as needed (preferably basing it on the previous *development* release if appropriate) -- until you *release* / publish such a version. How often does it happen that you really have to "back out" a ticket (patch, spkg) from a previous, published [devel] release? The IMHO proper way to go is to make such necessary [post publication] changes on follow-up tickets that get merged as usual, or at least create and commit inverse Mercurial patches, if you want to "completely" get rid of an already merged ticket in the first place. (The merge history remains in that case, and other developers can easily apply such "undo" patches to their versions if they like -- just like any other patch.) Frankly said, it is currently *too easy* (for the release manager) to abandon changes made to previous, already published [devel] releases -- as if they never happened. And whether that's beneficial to the development and review process is at least questionable. 2ct, -leif -- 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
