Jeroen Demeyer <jdeme...@cage.ugent.be> writes: > On 2012-03-06 05:49, Keshav Kini wrote: >> Hi Jeroen, >> >> If I understand correctly, your reasoning for basing new development >> releases on the previous stable release rather than the previous >> development release is that sometimes a ticket may be merged into a >> development release but then need to be removed from a subsequent >> development release due to problems that were found later, or an SPKG >> that was upgraded needs to be downgraded again. > > Another important reason is that I sometimes work on more than one Sage > version at the same time. While putting together sage-5.0.beta7, I was > already merging stuff in sage-5.0.beta8. This gets harder with what you > propose.
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? If so, I don't see how my proposal would make that any harder. But maybe I'm totally wrong about that. What is involved? > It's also harder to deal with "exceptional" cases. Like the problem we > had with sage-5.0.beta6 where two files were missing from the > distribution. It's easier to go back and do it the right way, as > opposed to fixing it afterwards. > > Another example: #11235. While checking all spkgs for uncommitted > changes, I discovered the spkg there contained some garbage. I simply > removed the garbage and put up a new spkg with the same version number. > With your proposal, this would probably have involved creating a new > ticket instead of making the trivial adjustment in a subsequent Sage > version. Huh? If you think a new ticket would be required for adding a commit to the SPKG to back out the committed garbage, why do you think a new ticket is *not* required for putting up a new spkg with the same version number? Personally I don't think a ticket is required for either one. > Obviously, reverting a patch would become more difficult, I don't even > know the "right" way to do it with Mercurial. Would become, in what situation? I'm not sure what you mean. The right way to back out a previous commit without just deleting it is to use `hg backout`, as I said. > Why doesn't git/hg consider the version sage-5.0.beta0 inside > sage-5.0.beta6 the same as version sage-5.0.beta0 inside sage-5.0.beta7? > They should be identical (apart from timestamps). It does, actually - my mistake. It does not consider the version sage-5.0.beta1 inside sage-5.0.beta6 the same as version sage-5.0.beta1 inside sage-5.0.beta7, though. Timestamps are factored into the calculation of commit IDs. The timestamps of patches are written into the patch files themselves, so they do not differ (unless you edit patches between development releases, which I assume you don't). The problem is your commits which are called e.g. "Added tag 5.0.beta0 for changeset 63e6cb54ca9f", in which you commit the new tags to the .hgtags file. Those have different timestamps each time you build a dev release, which causes the branching, even if the patches you apply remain the same. Another problem is your commits called e.g. "5.0.beta0", in which you put the correct version number in version.py. The commit in which you put the version number "5.0.beta0" in version.py is omitted from the history you create when you make Sage 5.0.beta1. These disappearing version number commits and changing-timestamp .hgtags commits together cause the branching effect. (That's why beta0 is still cohesive among the various branches - your problematic commits start happening after the patches in beta0.) -Keshav ---- Join us in #sagemath on irc.freenode.net ! -- 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
