On Tue, Dec 07, 2010 at 05:47:23PM +0100, Thomas Keller wrote: > > Hi all! > > I appreciate that people take care about older releases and open > branches for them to backport fixes, but I think two things are easily > forgotten and should be considered by anybody touching these: > > 1) If a new branch is created off trunk for a patch release and you make > your first commit, its your responsibility to change the version number > to "0.<minor>.<patch + 1>dev" for mtn < 1.0. If we follow the new > proposed version numbering scheme, this would mean > <major>.<minor>.<patch>.90 for new patch versions, which eventually gets > <major>.<minor>.<patch + 1>, but I'm open for other - less ugly - > suggestions here.
Do we run the risk of several patch branches being extant simultaneously and ending up with the same 0.minor.patch+1 number? Presumably this would have to be changed when finally merging the patch. > > 2) Likewise when the first change is made, a corresponding NEWS entry > should be written, so we don't start to digg though the commit log of > the particular branch for a patch release, but have something to build upon. > > 3) Usually one would fix a bug in a release branch and merge it into > trunk, but this merge could bring over unwanted changes (like changes in > NEWS, configure.ac and maybe others), so the best is probably to use > pluck as most of you already did. > > > Now to the question which branches we really want to take care of. > > Since 0.48 is quite around I think it makes sense to support this a > little longer - at least until Debian moves to a newer version - and > backport important stuff as needed. That'll be a long time, sonce 0.48 is currentl;y Debian testing, and will be around as stable for a very long time. Unless we can get 1.0 into testing before the release. Which I consider unlikely. > Richard recently added the updated French translation to 0.48 (probably > because the original author created a patch against this version) and > this was already kind of a corner case, because I think we should really > try to keep calm in this area and avoid lots of work backporting > non-crucial things to older branches. > The translation update of course did not break anything for us, but I > don't know for example if Debian policies allow i18n updates at all in > the lifetime of a package and if this work is actually seen for 0.48 > users. (I do think its seen otherwise the original author wouldn't have > send the patch probably, but I don't know the rules enough). > > Other versions beside 0.48 are currently not quite on my agenda beside > the most recent version / branch 0.99, so again, unless people start > screaming very loud at us we should try and keep the work and ourselves > calm. I think 0.40 is in Debian stable right now, but that should be gone in a few months.(or at least become oldstable). > > Questions / comments / clarifications? If you're ok with the things > written above, I could move them into the wiki and / or document them in > notes/release-checklist.txt. > > Thomas. > > -- > GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz > Please note that according to the EU law on data retention, information > on every electronic information exchange might be retained for a period > of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en > > > _______________________________________________ > Monotone-devel mailing list > Monotone-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/monotone-devel _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel