Anika Henke, 2011-05-30 16:51 UTC+0100: > I'm not sure for the reasons why this is so. But this script might > help to find the (official) differences: > http://www.dokuwiki.org/devel:release#tarball_build_script Good, so I have an official list of changes. Now, I recommend this to be implemented as a Git branch. Thus, preparing a new release would be as easy as: $ git checkout tarball $ git merge stable # or whatever branch you want to release By the way, I will also reiterate a suggestion I think I already made but that may have been forgotten: naming the release branches according to the release names. Currently there is a single stable branch and the merge of the master branch into it looks quite artificial to me. For instance, consider the following case: 1. a new release is made, creating or updating the stable branch; 2. some development is made on the master branch; 3. a bug is corrected on the master branch (it wuold have been better to do it in a dedicated branch forked from master and stable's common ancestor, but nobody is perfect); 4. this fix is backported to the stable branch; 5. a new fix release is made; 6. now a new release is made: merging master into stable will try to integrate this fix commit twice (I do not know how Git manages that, but I think it should be avoided). Basically, a release is a fork of the development code, and has no reason to depend on previous releases, that is why I think it should be better (easier for people *and* for Git itself) to use a branch for each release. To connect this to my previous suggestion, here is how I imagine the branches could relate to each other: master | tarball | | rincewind ↓ | ↓ o | o | ↓ / anteater o / ↙ | o o ← fix 2 o /| | |/ | | o | o ← fix 1 | | / o |/ | o ← remove files not to be on the tarball o / |/ o -- ,--. : /` ) Tanguy Ortolo <xmpp:tanguy@xxxxxxxxx> <irc://irc.oftc.net/Elessar> | `-' Debian Maintainer \_