[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [recommenders-dev] Proposal: A branching model for Code Recommenders "Next"
|
Hi Andreas,
I guess it makes much more sense to ask you my questions face to face next week when back in DA, but… :-)
I guess you already looked on how other projects build their code. Did you also check how Eclipse Platform is working?
AFAICT, common practice of platform team is that they always work on master and have an "integration" branch which get's updated whenever master is in a good state for a release [1]. Maybe their approach would work for us too?
*just expressing my current feelings below*
Do we actually need all these next/ next/new-jayes etc. branches? I think feature branches are a good thing but they should be merged into master from time to time and master should be our 2.0 branch. Kepler and Juno get their maintenance branches. I think master + integration + feature branches sound good enough to me.
M.
[1] http://wiki.eclipse.org/Platform-releng/Git_Workflows#Contributing_to_a_build
--
Codetrails.com – The knowledge transfer company
On Feb 21, 2013, at 12:15 PM, Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx> wrote:
> Hi all,
>
> today I had a discussion with Michael about how to bring his
> improvements to the Jayes library to Code Recommenders and how to
> proceed with developing API-breaking changes/features in general.
>
> We came up with the following branching model:
>
> master
> |
> |
> | kepler
> o |
> |\ |
> | \|
> o o = a bugfix that needs to go into Kepler
> | /
> |/ next/jayes
> o |
> | | next
> | | |
> o o o next/models-api
> | | /|\ |
> | |/ | \|
> o o | \
> | | | |
> | | | |
> o o | o
> | \ | /
> | \|/
> o-----------o
> |
> |
> o = today
>
> So, let's parse that from top to bottom:
>
> "master" will still be the branch where non-breaking 1.x stuff (probably
> mostly bug fixes) will occur. Once in a while, a release branch like
> "kepler" forks of (this is the point where the project versions are
> incremented in "master").
>
> If during the weeks before the official release, e.g., of Kepler a bug
> is found in that branch, it is fixed there and then the bugfix is also
> merged into the "master" branch. (Merging "master" into "kepler" is
> obviously a bad idea; save for bugfixes a branch like "kepler" should
> sit around quietly.)
>
> The API-breaking changes will be developed in feature branches like
> "next/jayes" or "next/models-api" and occasionally (e.g., (bi?)weekly)
> merged into a "next" branch. On the "next" branch itself, no non-merge
> commits will be made. All "next" development happens in the feature
> branches. All "next*" branches will share a version of 2.0.0-qualifier.
>
> And since "master" is relatively stable we can treat it as just a
> special kind of feature branch for "next" and occasionally merge it into
> "next" as well.
>
> If all goes well, we can finally (in time for Kepler SR1 perhaps) merge
> "next" back into "master" (which will then become a 2.0.0-SNAPSHOT
> branch) and branch of "kepler-sr1" from there.
>
> Does this sound like a reasonable model to you?
>
> Best wishes,
>
> Andreas
> --
> Codetrails.com - the knowledge transfer company
> _______________________________________________
> recommenders-dev mailing list
> recommenders-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/recommenders-dev
