[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[recommenders-dev] Proposal: A branching model for Code Recommenders "Next"
|
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
