As I'm involved in the planning: +1 ;)
Note that these plans don't affect the recommenders.incubator projects codesearch and args. You can follow the same branching strategy but don't have to. As there are no releases to maintain compatibility with this seems to be overhead.
Best, Marcel
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 _______________________________________________ recommenders-dev mailing list recommenders-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/recommenders-dev
|