On Fri, 15 May 2009, Raphael Hertzog wrote: > Don, what do you consider best-practice in terms of changelogs > merging?
In the BTS's view of versioning, a version is based on exactly one preceeding version. This version is currently the version immediately preceeding the uploaded version according to the changelog file. In the case of experimental uploads merged into unstable packages, the changelog generally shouldn't include the changelog entries from experimental, as the package only contains the changes merged from experimental (not other changes in the upstream version, for example). [But specific changelog sub-items from the experimental changelog that correspond to bugs fixed in the stable package should of course be there.] You'd basically have the following (u=unstable, e=experimental): u:1<--u:1.1<-u:1.2<-u:1.3<-u:2.4 ^ ^ ^ | | | e:2 | | ^ e:2.2 | | e:2.3 e:2.1 with the order of the changelogs following the arrows. In the future, it'd be nice to be able to come up with some sane way of representing that the e:2.3 upload actually had the changes made in e:2.2, e:2.1 and e:2. Unfortunatly, while I've thought about this for a while, I haven't been able to come up with a method that is easy to implement, understand, and is actually an improvement over the status quo. Don Armstrong -- If you find it impossible to believe that the universe didn't have a creator, why don't you find it impossible that your creator didn't have one either? -- Anonymous Coward http://slashdot.org/comments.pl?sid=167556&cid=13970629 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
