Potential discussion topic for status/planning/architecture
Wanted to give a quick summary of our branches, and
what component teams need to do as they branch (or not).
map project branches:
master: used for Kepler (4.3) I builds and N builds.
Few teams (only swt?) need to touch anything here. Its repositories.txt
file uses 'master' or 'integration' for (nearly) all projects to enabled
auto detection of changes and auto-tagging.
R3_8_maintenance (3.8.1) R4_2_maintenance (4.2.1):
the repositories.txt files here will need attention, at some point, only
one time. Many of the repository lines have been "commented out",
meaning a) assumed no maintenance branches yet and b) what is used for builds is exactly what was used
in the respective release (3.8 or 4.2).
*** One time action required: As teams begin maintenance,
and make a branch, they will need to edit these repositories.txt file files
so their new branches are listed to be used in the maintenance builds.
Example snippet from repositories.txt in R4_2_maintenance
This (snippet) means that two projects rt.equinox.incubation
and rt.equinox.p2 have maintenance work in R3_8_maintenance, so those are
Other projects, commented out, such as eclipse.jdt.core
does not have maintenance work yet, so what's used is in build, is what
was used in the 4.2 map files.
Once, say eclipse.jdt.core begins maintenance for
4.2.1 (if any) they will need to create their branch, according to their
project's conventions, and put that in place of the tag. (here, the tag
is R3_8, which does not have any particular meaning ... was just one attempt
to address the "no branches yet" issue before deciding to comment
out repositories with no branches).
Feel free to open a bug in releng if you want help
or review when you update this repositories.txt file.