Hey guys, I've seen that there are no tags of the current releases at pax-web. @Guillaume you may like to push them too? (git push --tags)
BTW @Release-Branches and Maven (paxweb-0.7.x). Thre is some quirks between the way the maven release plugin and git works with this classical svn model... (This is some git-problem now; I hope I can keep it simple; please ask if not :)). Ok lets start: There are two possible workflows with git and support (AFAIK) (these branches with the x in the version number; e.g. paxweb-0.7.x) branches: a) commit changes on support branch OR master and cherry-pick them to the other side. (+) no pain, simply pick required commits (-) loosing history between fix on master and fix on support branch (a cherry pick creates a NEW commit (new parents and childs --> new sha1 --> new commit)) (-) cherry-picks with "more" commits are either painful often execution of cherry-pick or quite complex git-rebase actions b) either change directly support branch and merge it into master (or better) branch off support branch and merge into master and support. (+) history is kept (+) very easy to handle (-) many merge nodes BUT using (b) there's a serious problem now with the way git (and the mvn-release-plugin) works. (1) you really have to start chagnes you want to have in the master based on the support branch; otherwise the "back-merge" will also include all other commits done in the master; and I'm sure we do not want that. (2) if we directly do the work in the support branch and merge this one back to the master you (2a) also add all other changes you've done to the support branch (ok, this is typically not so bad because it only reflects that there should be no infrastructural changes in support branches anyway) BUT (2b) you also apply the changes in the pom files (and this is a real pain). I hope that the second problem is clear. You apply the commits version increased, version back to snapshot commits which are afterwards merged into the master and change the version there too. At openengsb.org (for example) we solve this problem now by using a support-dev and support-release branch. The support-release branch is not merged back into the support-dev branch and the releases of the support-branch are done by mergeing the support-dev branch into the support-release branch and doing the release there. The work is going on in support-dev till the next release where we merge support-dev again into support-release (you may like to take a look at [1] to see what I'm talking about). In a nutshell: model (a) is easier but really has some quirckses about the history (IMHO) and can become quite unlogical in the git-way-of-doing things. Model (b) requeires much more discipline by developers but produces (IMHO) the better outputs in history graphs and understanding the history of a project. Sorry for the long post, but I really thing we should discuss this :) kind regards, andreas [1] https://github.com/openengsb/openengsb/network
pgp7Wg8EPIa68.pgp
Description: PGP signature
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
