it is great when you really need to work on release and often squash commits, we dont do it @asf.
+ dont forget theory != practise and most of the time overhead to get a nice theory is useless (why we still use newton law even if we know they are wrong ;)) Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-28 22:59 GMT+01:00 Thiago Veronezi <thi...@veronezi.org>: > Hmmm... I think I see how it works now. It starts to make more sense. :) > Something doesn't feel right though. Why Gitflow is so popular? How would > it protect the companies from having bad commits? I need to think about it. > Just wanted to let you know that I see your point. > > []s, > Thiago. > > > On Wed, Jan 28, 2015 at 4:32 PM, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > >> 2015-01-28 22:29 GMT+01:00 Thiago Veronezi <thi...@veronezi.org>: >> > But if you only have master, any quick fix would bring unnecessary >> baggage, >> > right? >> > I mean, merging the fix changes from 2.x.x to master would be trivial >> > because it would only contain changes for that particular fix. >> > >> > If the release tags are on master, for a quick fix, we would need to >> create >> > a new branch from the latest release tag, do the fix in the new branch >> and >> > release it again. Where would this new release tag live? Do we keep this >> > new branch just to hold a minor code change for a bug fix? >> >> If that's a fix for a recent release we just create a branch for the >> release, release, tag, delete the release branch - like we'd have do >> it just after the release ignoring all commit in between. >> >> Otherwise you are back to current status = you merge all commit done >> on 2.x on master which is: >> 1) useless >> 2) makes a lot of noise when done >> 3) makes getting started not obvious (need doc) >> >> >> > >> > []s, >> > Thiago >> > >> > >> > On Wed, Jan 28, 2015 at 4:17 PM, Romain Manni-Bucau < >> rmannibu...@gmail.com> >> > wrote: >> > >> >> well you shouldn't rebase/merge from a lower to upper branch IMO - ie >> >> it is always fixed first on mainstream then backported if needed - or >> >> just dev in the lower version if specific. >> >> >> >> That said this doesn't justify 2.x while master = 2.x >> >> >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau >> >> http://www.tomitribe.com >> >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> >> >> >> 2015-01-28 22:12 GMT+01:00 Thiago Veronezi <thi...@veronezi.org>: >> >> > Maybe it can be something like... >> >> > >> >> > Quick bug fix in 2.x.x: >> >> > * You fix your issue in "2.x.x" >> >> > * Call a vote for "2.x.x". >> >> > * The vote passes. You merge "2.x.x" back to "master". >> >> > * You create a new tag in 2.x.x -> Let's call it "tag 2.0.2" >> >> > >> >> > Normal 2.x.x release >> >> > * You rebase "2.x.x" >> >> > * You follow the same steps as the ones for "quick bug fixes in 2.x.x" >> >> > >> >> > This way we avoid the auxiliary branches. We just need to be sure that >> >> > "2.x.x" is not a development branch. It needs to be stable. So, once >> we >> >> > rebase it, we need to make it stable before merging it back to master. >> >> > "2.x.x" is the branch that contains the release tags. >> >> > >> >> > []s, >> >> > Thiago. >> >> > >> >> > >> >> > On Wed, Jan 28, 2015 at 4:07 PM, Thiago Veronezi <thi...@veronezi.org >> > >> >> > wrote: >> >> > >> >> >> Hi, >> >> >> This is what I was thinking... >> >> >> >> >> >> Quick bug fix in 2.x.x: >> >> >> * You create a new auxiliary branch from 2.x.x. -> Let's call it >> "2.0.2" >> >> >> as example >> >> >> * You fix your issue in this new "2.0.2" branch >> >> >> * Call a vote for "2.0.2". >> >> >> * The vote passes. You merge "2.0.2" back to "2.x.x". >> >> >> * You create a new tag in 2.x.x -> Let's call it "tag 2.0.2" >> >> >> * You destroy the auxiliary branch "2.0.2" >> >> >> * You merge "2.x.x" back to master. >> >> >> >> >> >> Normal 2.x.x release >> >> >> * You rebase "2.x.x" >> >> >> * You follow the same steps as the ones for "quick bug fixes in >> 2.x.x" >> >> >> >> >> >> []s, >> >> >> Thiago. >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Jan 28, 2015 at 3:54 PM, Romain Manni-Bucau < >> >> rmannibu...@gmail.com >> >> >> > wrote: >> >> >> >> >> >>> If I have a fix to do in 2.x, where do I code? 2.x.x or master? >> While >> >> >>> master = 2.x I'm not convinced we need it. Doesnt solve the need of >> a >> >> >>> release branch while mvn tools are not compliant with tomee setup. >> >> >>> >> >> >>> >> >> >>> Romain Manni-Bucau >> >> >>> @rmannibucau >> >> >>> http://www.tomitribe.com >> >> >>> http://rmannibucau.wordpress.com >> >> >>> https://github.com/rmannibucau >> >> >>> >> >> >>> >> >> >>> 2015-01-28 21:52 GMT+01:00 Thiago Veronezi <thi...@veronezi.org>: >> >> >>> > Please note that having "2.x.x" covers all the requirements: >> >> >>> > * master is the bleeding edge - it doesn't need to be stable >> >> >>> > * no code-freeze necessary >> >> >>> > * stable and ready for production "2.x.x" branch >> >> >>> > * quick bug fix release possible without interrupting development >> on >> >> >>> master >> >> >>> > >> >> >>> > []s, >> >> >>> > Thiago. >> >> >>> > >> >> >>> > On Wed, Jan 28, 2015 at 3:34 PM, Romain Manni-Bucau < >> >> >>> rmannibu...@gmail.com> >> >> >>> > wrote: >> >> >>> > >> >> >>> >> 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 >> >> >>> >> >> >> >>> >> >> >> >> >> >> >> >> >>
