What about having something like this? https://dl.dropboxusercontent.com/u/1459144/tomee_git.jpg
* master is the place we push bleeding edge stuff. * 1.7.x is stable and will never get back to master. We create our current release tags (bug fixes, tomcat upgrades etc) out of it. * 2.x.x is stable and contains code out of master (rebase). During release, we rebase this branch, create auxiliary branches out of it for voting purposes. Once the voting passes, we merge it back to 2.x.x, create the release tag out of 2.x.x and delete the auxiliary branch. []s, Thiago. On Wed, Jan 28, 2015 at 12:32 PM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > answering inline > > 2015-01-28 18:13 GMT+01:00 Thiago Veronezi <thi...@veronezi.org>: > > Hi Mark, > > > >>>1.) trunk/master is the 'next planned big release'. Most of the work > > happens there. > > > > As "master" is just a branch, it means we are simply renaming "develop" > to > > "master". That would save a couple of keystrokes indeed. Instead of... > > git checkout -b my_local_branch origin/develop > > > > +1 > > > ... we would do... > > git checkout -b my_local_branch > > > >>>2.) For each released version we have a tag. If we need maintenance on > > those (like we have with 1.7.x then we simply create a maintenance branch > > for it. > > > > We create this tag from where? "origin/master"? If so, we would need to > > have a kind of code-freeze once "master" is stable and until we have our > > release tag ready. Our voting spans up to 3 days, maybe more. It means we > > wouldn't be able to push our local changes of on-going tasks until the > > release passes. Did I get it right? > > > > we take the last maintainance branch, add the few fixes we need and > then create the release branch and release from here. Once the vote > passed the RM pushes the tag. If it doesnt we can either delete the > release branch or fix it if it is minor. > > Of course if the diff between last maintaince branch and the fix we > want to do - assume we want to fix something in 1.0 now - we'll create > another maintaince branch from the 1.0 tag. > > I'd like a master which is our old trunk = not an issue if not stable, > that's the branch interesting guys going to sources so let it be the > default. > > > Gitflow proprosal: > > * we create a branch out of "develop" called "tomee-2.0.0" (for example). > > * we make "tomee-2.0.0" stable and call a vote. meanwhile, the developers > > are free to push to "develop" > > * "tomee-2.0.0" passes. we merge the code to "master" and to "develop" > (in > > case minor changes were necessary) > > * we create a release tag out of "master" because this branch is supposed > > to be stable. > > > >>> 3.) If there is a need for a hotfix then simply grab the tag of the > > release and create a branch from it. Then just apply the fixes you really > > need and no bit more. > > > > Yeah, it seems simple enough. I have no problem with it. In fact, this > > looks like what gitflow proposes. :) > > > > So, I guess we need to decide where the main development will happen > > (develop or master), and whether code-freeze is acceptable or not. > > > > []s, > > Thiago. > > > > > > On Wed, Jan 28, 2015 at 8:27 AM, Romain Manni-Bucau < > rmannibu...@gmail.com> > > wrote: > > > >> @Thiago: if there is a security fixes we'll start from a tag anyway, > >> not from master > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2015-01-28 14:23 GMT+01:00 Mark Struberg <strub...@yahoo.de>: > >> > thiago, there is absolutely no sense in all the gitflow stuff. The > more > >> I think about it the more I come to the conclusion they never did a big > >> project yet. > >> > > >> > Really the ONLY reason for such a workflow is if you have tons of > >> uneducated juniors working on the codebase and trashing your project by > >> committing more bad things than good things. But I hope that is NOT the > >> case for ASF projects... > >> > Btw, for such projects I'd rather suggest to use gerrit and not > >> gitflow... > >> > > >> > > >> > > >> > How does it work usually. > >> > > >> > 1.) trunk/master is the 'next planned big release'. Most of the work > >> happens there. > >> > > >> > > >> > 2.) For each released version we have a tag. If we need maintenance on > >> those (like we have with 1.7.x then we simply create a maintenance > branch > >> for it. > >> > > >> > 3.) If there is a need for a hotfix then simply grab the tag of the > >> release and create a branch from it. Then just apply the fixes you > really > >> need and no bit more. > >> > > >> > That works that way since years and I've never seen any issues. > >> > > >> > > >> > The point is that it doesn't make much sense to do all the work > upfront > >> because you _might_ need it. Just do the work IF you need it instead. > >> That's really easy to do with GIT. > >> > > >> > LieGrue, > >> > strub > >> > > >> > > >> > > >> > > >> > > >> >> On Wednesday, 28 January 2015, 14:05, Thiago Veronezi < > >> thi...@veronezi.org> wrote: > >> >> >>> ...oops for tomee you dont get the snapshot > >> >> I agree. But that's the whole point. We shouldn't get the snapshot > from > >> >> master, according to the "Gitflow". I think it pays off when we have > a > >> >> hotfix like critical security bugs. Instead of rushing all the > on-going > >> >> tasks in order to close them for a new release, we would simply > create a > >> >> hotfix branch out of master, do the fix and merge it to develop and > >> back to > >> >> master. The link Andy provided has a chart that shows exactly how it > >> would > >> >> help. See the "hotfixes" line: http://nvie.com/img/git-mo...@2x.png. > >> >> > >> >> If the "pom.xml" file in "origin/master" does not use the > >> >> "SNAPSHOT", it > >> >> raises a flag to the developer. "Where the hell are the snapshots?" > :) > >> >> She/he would need to switch to the develop branch. > >> >> > >> >> []s, > >> >> Thiago. > >> >> > >> >> > >> >> > >> >> On Wed, Jan 28, 2015 at 7:09 AM, Romain Manni-Bucau > >> >> <rmannibu...@gmail.com> > >> >> wrote: > >> >> > >> >>> was the idea but: > >> >>> - doesnt make sense @asf > >> >>> - are we numerous enough to commit to let it get any sense? > >> >>> - do we want this ability at all? > >> >>> > >> >>> IMO we dont > >> >>> > >> >>> master = 2.0.0-SNAPSHOT = last version of the main version so it is > >> >>> not wrong even if not sexy. > >> >>> > >> >>> What we'll do basically when releasing is just merging all to > master > >> >>> if we keep develop so we just added noise for external guys > >> >>> > >> >>> > >> >>> When you go on github what do you do? > >> >>> > >> >>> git clone xxxxx > >> >>> cd xxxxx > >> >>> mvn clean install > >> >>> > >> >>> > >> >>> ...oops for tomee you dont get the snapshot > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> Romain Manni-Bucau > >> >>> @rmannibucau > >> >>> http://www.tomitribe.com > >> >>> http://rmannibucau.wordpress.com > >> >>> https://github.com/rmannibucau > >> >>> > >> >>> > >> >>> 2015-01-28 13:06 GMT+01:00 Thiago Veronezi <thi...@veronezi.org>: > >> >>> > Hi, > >> >>> > > >> >>> > If I get it right... > >> >>> > > >> >>> > * "origin/master" is just a regular branch, and a branch > >> >> represents what > >> >>> we > >> >>> > want it to be. For the "gitflow", "origin/master" > >> >> is our latest release. > >> >>> In > >> >>> > this case, if someone performs a checkout of master and builds > the > >> >>> > application from it, she/he will build the 1.7.1 distribution. > Note > >> >> that > >> >>> > currently it points to "2.0.0-SNAPSHOT". So maybe it is not > >> >> in good shape > >> >>> > because this source code it is not production ready. > >> >>> > * "origin/develop" is our tomee 2.0 > >> >>> > * "origin/tomee-1.7.x" is our tomee 1.7.x > >> >>> > > >> >>> > If we talk about commands, we would use the following in our > >> >> development > >> >>> > process [Just tested it to be sure. :) ]... > >> >>> > > >> >>> > // check out the source code. "origin/master" is the > >> >> default. We don't > >> >>> > commit to this guy. > >> >>> > git clone https://git-wip-us.apache.org/repos/asf/tomee.git > >> my_source > >> >>> > Cloning into 'my_source'... > >> >>> > remote: Counting objects: 236092, done. > >> >>> > remote: Compressing objects: 100% (73416/73416), done. > >> >>> > remote: Total 236092 (delta 115784), reused 233010 (delta 114168) > >> >>> > Receiving objects: 100% (236092/236092), 35.93 MiB | 986 KiB/s, > >> done. > >> >>> > Resolving deltas: 100% (115784/115784), done. > >> >>> > > >> >>> > // go to new directory > >> >>> > cd my_source > >> >>> > > >> >>> > // create a local "develop" branch for for tomee 2.0 from > >> >>> "origin/develop" > >> >>> > git checkout -b develop origin/develop > >> >>> > Branch develop set up to track remote branch develop from origin. > >> >>> > Switched to a new branch 'develop' > >> >>> > > >> >>> > // create a local "feature" branch for for tomee 2.0 from > >> >> the local > >> >>> > "develop" > >> >>> > git checkout -b cosmetic develop > >> >>> > Switched to a new branch 'cosmetic' > >> >>> > > >> >>> > // now we work on the tomee 2.0 feature and commit > >> >>> > git status > >> >>> > git add pom.xml > >> >>> > git commit -m "moving end tag up" > >> >>> > > >> >>> > // ready to merge back to develop > >> >>> > git checkout develop > >> >>> > > >> >>> > // update develop > >> >>> > git pull > >> >>> > > >> >>> > // merge our local branch > >> >>> > git merge cosmetic > >> >>> > Updating edaf6d2..21ad55b > >> >>> > Fast-forward > >> >>> > pom.xml | 3 +-- > >> >>> > 1 file changed, 1 insertion(+), 2 deletions(-) > >> >>> > > >> >>> > // push to remote develop > >> >>> > git push > >> >>> > > >> >>> > // delete local branch > >> >>> > git branch -d cosmetic > >> >>> > Deleted branch cosmetic (was 21ad55b). > >> >>> > > >> >>> > // if we have a new feature, we repeat step from this step... > >> >>> > git checkout -b new_feature develop > >> >>> > ... > >> >>> > > >> >>> > > >> >>> > Basically, we don't touch "origin/master". Only when we > >> >> merge > >> >>> > "origin/tomee.1.7.x" (or "origin/develop") back to > >> >> it. > >> >>> > I don't see a problem. We just need to keep in mind what > >> >> "origin/master", > >> >>> > "origin/develop" and "origin/tomee.1.7.x" > >> >> represent. > >> >>> > > >> >>> > Is that right? > >> >>> > > >> >>> > []s, > >> >>> > Thiago. > >> >>> > > >> >>> > > >> >>> > On Wed, Jan 28, 2015 at 4:59 AM, Romain Manni-Bucau < > >> >>> rmannibu...@gmail.com> > >> >>> > wrote: > >> >>> > > >> >>> >> well it is by design opposed to apache way since if it is used > it > >> >> is > >> >>> >> to have the ability to change commit history - if not it is > really > >> >>> >> useless. > >> >>> >> > >> >>> >> > >> >>> >> Romain Manni-Bucau > >> >>> >> @rmannibucau > >> >>> >> http://www.tomitribe.com > >> >>> >> http://rmannibucau.wordpress.com > >> >>> >> https://github.com/rmannibucau > >> >>> >> > >> >>> >> > >> >>> >> 2015-01-28 10:57 GMT+01:00 Andy Gumbrecht > >> >> <agumbre...@tomitribe.com>: > >> >>> >> > I know I set it up this way, but I am really +0 at the > >> >> moment. I don't > >> >>> >> feel > >> >>> >> > any anger towards it though. It is not 'my way', > >> >> rather the Gitflow > >> >>> way. > >> >>> >> > > >> >>> >> > I'm not going to push it other than to point to the > >> >> description of > >> >>> >> Gitflow. > >> >>> >> > It's only going to make sense if you use it, and then > >> >> really only if > >> >>> you > >> >>> >> > play release manager, and then only if you are managing both > >> >> 1.7.x and > >> >>> >> > develop releases. > >> >>> >> > > >> >>> >> > The scenario is described here in extreme detail - > >> >>> >> > > >> >>> >> > >> >>> > >> >> > >> > https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow > >> >>> >> > > >> >>> >> > It just 'looks' future safe to do it that way, and > >> >> until the Gitflow > >> >>> has > >> >>> >> > been tried and tested on the upcoming releases we will not > >> >> know. Jon > >> >>> >> should > >> >>> >> > give us his feedback after the releases are done. And then we > >> >> should > >> >>> all > >> >>> >> > look at the repo. The decision to use it was based on that > >> >> description > >> >>> >> and > >> >>> >> > they guy who 'invented' it - > >> >>> >> > http://nvie.com/posts/a-successful-git-branching-model/ > >> >>> >> > > >> >>> >> > I actually don't know what is so painful about using > >> >> '-b develop' on > >> >>> the > >> >>> >> > initial developer checkout? That's it, everything else is > >> >> identical. > >> >>> As a > >> >>> >> > developer it is trivial. Where are the hard line drawbacks to > >> >> it other > >> >>> >> than > >> >>> >> > to say it's crap? Why is is so painful for some? I really > >> >> want to > >> >>> >> understand > >> >>> >> > what is causing the hate? > >> >>> >> > > >> >>> >> > The simple idea is that 'master' only ever contains > >> >> production ready > >> >>> >> code, > >> >>> >> > that's it. No more no less. > >> >>> >> > > >> >>> >> > Anyway, if everyone agrees on a way forward then votes on it > >> >> then I > >> >>> >> really > >> >>> >> > am +0, as it is not hard to do it either way. > >> >>> >> > > >> >>> >> > That doesn't mean: > >> >>> >> > -1 It's crap! > >> >>> >> > > >> >>> >> > That does mean: > >> >>> >> > -1 It's crap because.... and I will document 'my > >> >> way' for everyone to > >> >>> >> follow > >> >>> >> > to the letter. > >> >>> >> > > >> >>> >> > Andy. > >> >>> >> > > >> >>> >> > > >> >>> >> > On 28/01/2015 09:55, Romain Manni-Bucau wrote: > >> >>> >> >> > >> >>> >> >> hehe feel less alone now, +1 > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> Romain Manni-Bucau > >> >>> >> >> @rmannibucau > >> >>> >> >> http://www.tomitribe.com > >> >>> >> >> http://rmannibucau.wordpress.com > >> >>> >> >> https://github.com/rmannibucau > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> 2015-01-28 9:53 GMT+01:00 Mark Struberg > >> >> <strub...@yahoo.de>: > >> >>> >> >>> > >> >>> >> >>> Hi folks! > >> >>> >> >>> > >> >>> >> >>> Just noticed that our branch naming schema in GIT is > >> >> still > >> >>> outerwordly > >> >>> >> >>> fucked up. > >> >>> >> >>> > >> >>> >> >>> > >> >>> >> >>> > >> >>> >> >>> Why don't we do it as everyone else does? > >> >>> >> >>> What does this crap of development branch do? > >> >> It's total nonsense to > >> >>> >> have > >> >>> >> >>> it! > >> >>> >> >>> > >> >>> >> >>> There is NO RTC for development at whole ASF except > >> >> for MAINTENANCE > >> >>> >> >>> BRANCHES maybe. All the standard community work is > >> >> CTR (Commmit Then > >> >>> >> Review) > >> >>> >> >>> That's a community wide modus operandi and we > >> >> should follow it as > >> >>> well. > >> >>> >> >>> > >> >>> >> >>> > >> >>> >> >>> So I for one will totally ignore this development > >> >> branch when > >> >>> working > >> >>> >> on > >> >>> >> >>> the TCK in the next days. > >> >>> >> >>> > >> >>> >> >>> Can we please finally merge in all the good work in > >> >> the development > >> >>> >> >>> branch to master and delete it finally? > >> >>> >> >>> > >> >>> >> >>> > >> >>> >> >>> LieGrue, > >> >>> >> >>> strub > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> -- > >> >>> >> >> Andy Gumbrecht > >> >>> >> >> https://twitter.com/AndyGeeDe > >> >>> >> >> http://www.tomitribe.com > >> >>> >> > >> >>> > >> >> > >> >
