Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Updates BuildBot, now links to GH

"Being a committer does not [only (wink)] mean you commit code, it means you are committed to the project."

Info
titleRepositoy structure

After the svn tag "beforeSvnRestructuring" the repository structure has changed, please refer to history for information before this tag

...

  1. Only bugfixes should be backported to active release branches (if they happen also there).
  2. Bugfixes should be backported by the committer who did the bugfix in trunk, if possible.
  3. If the committer does not, for an a reason, backport the bugfix, he should leave the original issue open with a remark that a backport is needed and a short explanation why he does not do the backport.
  4. Issues which that need a back port backport should be labelled as "back portbackport-needed". In this way we are able to spot issues to be backported, especially before a release is on it's way. 
  5. In no case should the Jira issue be closed without doing 1. or 2.
  6. When you backport something, if you know that it should not be backported in older releases, please pass the information.

...

Lets say we set a service as deprecated for release branch R18. This service will be part of R18 and will be removed in next release branch R19.

For instance, imagine we decide to create a next to be released R18 R19 branch.
We have on trunk :

...

When we create the R19 release branch, we have change on trunk :

  • addCatalogMember deprecated since="19.12xx"
  • deleteWorkEffortAssignment deprecated since="18.12"

We create Before creating the new R19 branch , and clean the trunk. Now on trunk we have we remove the services deprecated since R18. So the trunk contains only:

  • addCatalogMember deprecated since="19.12"xx"

On this basis we create the R19 branch.

An so on...

Following changes

...

Using Buildbot

Here is a small documentation whith most aspects to know

...