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. 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. Obviously, reverting a patch would become more difficult, I don't even know the "right" way to do it with Mercurial. 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). -- 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
