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 |
...
The committers of OFBiz are a core group of developers those contributors who have the ability to commit changes into the OFBiz source code repository. As the project has grown over the years, there have been more committers of projects, so we thought it would be a good idea to define what the roles and responsibilities of the committers are. These points below are based on discussions we recently had on the developers' list:
...
- 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.
...
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 a service as deprecated for a service, this service 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
...
- Upcoming Branch (only for commits only done to trunk, ie when not backporting)
| Info | ||
|---|---|---|
| ||
| As per our conventions, when the reporter or the assignee, or even another person who has reviewed, decides the issue is implemented, done or fixed (or any other resolution type) the issue should be CLOSED. |
After some time the following Jira reports will contain very useful information :
...
- 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
...