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? []s, Thiago On Wed, Jan 28, 2015 at 4:17 PM, Romain Manni-Bucau <[email protected]> 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 <[email protected]>: > > 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 <[email protected]> > > 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 < > [email protected] > >> > 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 <[email protected]>: > >>> > 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 < > >>> [email protected]> > >>> > 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 > >>> >> > >>> > >> > >> >
