well while master = 2.x.x I wouldn't create it but yes (Tomcat model basically is nice 1 maintaince branch by N-1 maintained version + trunk for last one).
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-28 20:48 GMT+01:00 Thiago Veronezi <thi...@veronezi.org>: > 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 >> >> >>> >> >> >> >>> >> >> >> >> >> >>
