Page History

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

...

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.

...

Handling deprecated services

We tag code deprecated deprecated services as a part of a release and  these code branch using the "<deprecated" element. Deprecated services will be removed from the next release branch when this new branch is created.

Lets say we set Release 17.XX as deprecated for a service, this service  a service as deprecated for release branch R18. This service will be part of Release17.XX R18 and will be removed in next Release 18.XX
Imagine we are the 30 december 2019 and we next release branch R19.

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

• addCatalogMember deprecated since="next releaseUpcoming Branch"
• deleteWorkEffortAssignment deprecated since="18.12"

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

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

We create the stable branche, and after clean the trunk. Now on trunk we have Before creating the new R19 branch 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

...

• Of course it's recommended to follow what's going on on MLs, especially dev ML.
• Following changes on wiki is also recommended, one way is to subscribe to the daily email changes (in your Preferences/Watches). If you don't want to see anything about other projects you may only watch OFBiz spaces
  OFBiz (Open For Business) Project Open Wiki
  OFBiz End-User Documentation
  OFBiz Project Administration Workspace
  OFBiz Requirements and Designs
  OFBiz Technical Documentation
  You will be then alerted about any changes just after they have been done (with links)

Using Buildbot

Here is a small documentation whith most aspects to know

...