On Wed, Nov 17, 2010 at 03:59, Andreas Pieber <[email protected]> wrote: > 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)
Done > > 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 :) I guess I need to re-read it ... I'm not very used to pure git dev yet ... > > kind regards, > andreas > > [1] https://github.com/openengsb/openengsb/network > > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
