Re: [recommenders-dev] Proposal: A branching model for Code Recommenders

[Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>]

Hi all,

> I guess it makes much more sense to ask you my questions face to face
> next week when back in DA, but… :-)

OK, here's what we have come up with after we finally had time to
discuss things in detail:

master

  o = today
  |
  o
  |\ luna
  o \
  |  o = releng / bugfix
  o  |
  |  o = tagged luna-M1
  o /
  |/
  o
  |
  o
  |
  o
  |\ luna
  o \
  |  o = another releng / bugfix
  o  |
  |  o = tagged luna-M2
  o /
  |/
  o
  .
  .
  .
  o = feature freeze for luna
  |\
  o \
  |  o = another releng / bugfix
  o /|
  |/ o = tagged luna-M6
  o /|
  |/ o = tagged luna
  o  |
  .  .
  .  .
  .  .
  |  o = yet another bugfix
  o /|
  |/ o = tagged luna-SR2 (end of life for luna)
  o /
  |/
  o

So, let's read this from top to bottom (from now into the future): If
one of the early milestones (M1-M5) approaches, we branch of to a "luna"
(or whatever the name of the release will be) branch, where the master
branch is tested and supplied with minor bugfixes. These bugfixes are
then merged back into the master. This continues for all the early
milestones, which still get new features in between the "branched-off"
stabilizing (but *not* during the stabilizing).

Once a feature freeze has been declared (around milestone 6), the "luna"
branch will stay branched off. Bugfixes are still applied there and
merged back into the master, but the branch will stay around for SR1 and
SR2.

The important thing is that the direction of merges is always from
"luna" to "master" and never the other way around. That way, no new
features will creep into either SR1 or SR2.

Hope this makes sense to everyone. Thoughts?

Andreas
-- 
Codetrails.com - the knowledge transfer company