The stable-3.0 branch has been created. Basically, a new branch is created around RC1 time so we can ensure people aren't jamming new features into the build. I have requested a new Hudson job for building this new branch.
Whether we put API-breaking stuff into master usually has depended on how we intend to do releases. In the past, LTTng had kept API-breaking stuff in their own branch since the code wouldn't be added until the next year's release and there were a number of minor releases between then. I personally prefer that master be the base of the next release (minor or major) and if there is a need for a separate branch due to future release issues, then we create that separate branch and separate Hudson job. This allows end-users to use updates-nightly consistently. It is always the next future release. So, in this case, I would not suggest we break API in master and that we instead add a master-4.0 branch for work that is meant for next June. When 4.0 is the next release (at least Feb), we can merge over into master. I can set up a separate Hudson instance for it and then users know what is what (updates-nightly-4.0 vs updates-nightly). This would also prevent LTTng from having to do the build. Feel free to comment. -- Jeff J. ----- Original Message ----- > From: "Marc-André Laperle" <marc-andre.lape...@ericsson.com> > To: "Linux Tools developer discussions" <linuxtools-dev@eclipse.org> > Sent: Monday, May 26, 2014 10:17:07 AM > Subject: Re: [linuxtools-dev] Branching strategy for Luna > > I am very much in favor of having the master branch be the "unstable" > Mars branch. It think it makes sense to have master always going and > branch off the more stable branches from it. That way, development that > includes major changes (API breaking) is not stalled. > > I was thinking we could do something like this: > > June: stable-3.x branch (work on SR1, SR1.5 and SR2 happens on this > branch) + v3.0.0 tag > September: v3.1.0 tag ... or 3.0.1 tag > December: v3.2.0 tag ... or 3.0.2 tag > February: v3.3.0 tag ... or 3.0.3 tag or ... > June: v.4.0.0 tag + stable-4.x branch > > What do others think? > Marc-Andre > > On 14-05-23 04:51 PM, Alexandre Montplaisir wrote: > > Hello Linux Toolers, > > > > I was wondering what is the planned git branching strategy for Luna? > > The API/Feature freeze is next Tuesday, so I assume a stable-3.x > > branch will be created, branching off from master, at that point. Is > > this correct? > > > > Then afterwards, would it be safe to put API-breaking (4.0) changes in > > master? We have a bunch of changes lined up on Gerrit, which are > > currently targeted at master. Most of it won't make it for Luna > > obviously, but we're wondering where we should put them afterwards. > > > > Thanks, > > Alexandre > > _______________________________________________ > > linuxtools-dev mailing list > > linuxtools-dev@eclipse.org > > https://dev.eclipse.org/mailman/listinfo/linuxtools-dev > > _______________________________________________ > linuxtools-dev mailing list > linuxtools-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/linuxtools-dev > _______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
