Re: [linuxtools-dev] Branching strategy for Luna

[Jeff Johnston <jjohnstn@xxxxxxxxxx>]

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.laperle@xxxxxxxxxxxx>
> To: "Linux Tools developer discussions" <linuxtools-dev@xxxxxxxxxxx>
> 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@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
> 
> _______________________________________________
> linuxtools-dev mailing list
> linuxtools-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
>