THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
"Being a committer does not [only 
] mean you commit code, it means you are committed to the project."
| Info | ||
|---|---|---|
| ||
After the svn tag "beforeSvnRestructuring" the repository structure has changed, please refer to history for information before this tag |
...
- Only bugfixes should be backported to active release branches (if they happen also there).
- Bugfixes should be backported by the committer who did the bugfix in trunk, if possible.
- 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.
- 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.
- In no case should the Jira issue be closed without doing 1. or 2.
- When you backport something, if you know that it should not be backported in older releases, please pass the information.
...
We tag deprecated services as a part of a release branch using the "<deprecated" element. Deprecated services will be removed from the next release packagebranch when this new branch is created.
Lets say we set a service as deprecated for Release 17.XXfor release branch R18. This service will be part of Release17.XX R18 and will be removed in next Release 18.XXnext release branch R19.
For instance, imagine we decide to create a next to be released R19 branch.
We have on trunk :
- addCatalogMember deprecated since="Upcoming 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 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
...
- 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
...