Apache OFBiz Release Plan

NOTE DEJ20060909: This document is still being created and is not a final draft, but should contain most of the operations needed to create a release. We may want to add more sections on preparing for a release such as more on testing, and stuff on the NOTICE, LICENSE, KEYS, etc files.

General Goals and Release Process

General Goals, Policies and Process 

The What, Why and How of Apache OFBiz

The basic structure and driving force behind OFBiz has a lot to do with the goals and actualization of the release process.

OFBiz is and always has been a community-driven open source project. There is no central commercial organization that drives the development of OFBiz or derives a project from the intellectual property of the software or other project assets. This is formalized now that OFBiz is a project in the Apache Software Foundation.

Because of this OFBiz always has been and always will be just what users who contribute to the project want it to be. There are many different individuals and groups involved with many different needs and our goal is to define and follow development and release policies that serve the needs of these parties.

So, let's start with that...

How Do I Decide What to Use

...

?

From a project user perspective there is one main question that can help determine which way they will want to get OFBIZOFBiz: Do I want to contribute to the open source project?

...

1. Get the code straight from the code repository (SVN) trunk and update frequently through development, and periodically even after production deployment
2. Get the code from the code repository (SVN) release branch and keep updated or patched regularly as fixes are committed and the branch stabilizes over time; when getting started choose the most recent branch, even if it is very new; when new release branches are created update to them soon after the branch is done
3. Get a built release package or the code from a release branch tag, and update as new pre-built release packages and tags are created; these will only represent fixes and unless a major issue arises they will be backward compatible and generally safe to update or patch to; when getting started choose a release branch that has been around for at least 2-3 months and that has no major outstanding issues in the issue tracker to assure that it has stabilized; when new release branches are created wait until you are ready to do a major upgrade and possibly need to modify your code and configuration, and wait at least until the prospective branch has stabilized before moving to it

General Release

...

Policies

• Release branches will be created approximately once per year. We have decided recently (February 2009) to use the same release numbering scheme than Ubuntu (for instance, 9.4 means released in 2009 in April). This information is used in backend footer to know wich Release.revision is used...
• The trunk will never go into a feature-freeze state but rather development will continue and contributions will be accepted both immediately before and after the cutoff revision for a release branchAn initial pre-built
• Once a release branch stabilizes a "stable" release tag and release package will be created and made available to help get people started with the branch

How to do an OFBiz Release

Steps for testing a revision or branch before a release:

1. For revision: svn export -r ${revision-number} http://svn.apache.org/repos/asf/incubator/ofbiz/trunk ofbiz
2. For branch: svn export http://svn.apache.org/repos/asf/incubator/ofbiz/branches/$\^{Image Removed}{branch-name} ofbiz
3. cd ofbiz
4. ant run-tests

5. Wiki Markup
   Check results... (search for \[JUNIT\])

6. cd ..
7. rm -Rf ofbiz/

Steps for a test snapshot type "release":

1. Example file-base-name: apache-ofbiz-incubating-4.0.0.RC1
2. svn export http://svn.apache.org/repos/asf/incubator/ofbiz/trunk ${file-base-name}
3. cd ${file-base-name}
4. echo ${revision-number} > REVISION
5. ant run-install
6. cd ..
7. zip -r ${file-base-name}.zip ${file-base-name}/
8. tar -czvf ${file-base-name}.tgz ${file-base-name}/*
9. gpg --output ${file-base-name}.zip.asc --detach-sig --armor ${file-base-name}.zip
10. gpg --output ${file-base-name}.tgz.asc --detach-sig --armor ${file-base-name}.tgz
11. openssl md5 ${file-base-name}.zip > ${file-base-name}.zip.md5
12. openssl md5 ${file-base-name}.tgz > ${file-base-name}.tgz.md5

Steps for creating a branch in preparation for a real release:

NOTE: these steps all start with an svn co command though it is not intended that this would be done each time such an operation is done, rather it is to show context with an expectation that those doing these operations would already have a checkout somewhere to start from.

1. Exaple branch-name: release4.0 (for a series of releases using 4.0.0, 4.0.1, 4.0.2, etc)
2. svn co https://svn.apache.org/repos/asf/incubator/ofbiz ofbizroot
3. cd ofbizroot
4. svn copy trunk branches/${branch-name}
5. svn commit -m "Created new branch: ${branch-name}"

• issued
• Patches on the release branch can be created and applied whenever users desire
• Follow on release tags and release packages will be issued when major problems are discovered and fixed, and periodically to represent a significant number of fixes and updates
• Each new release tag and release package will be represented by a third position version number change (since February 2009 seems that we will prefer to use the revision number for that)
• Because it needs too much work, at some point older releases will not be supported by the community (trunk patches not backported)

Steps for back-porting

...

a fix from the trunk to a release branch

...

:

1. cd into the checked out release branch folder
2. $
3. svn co https://svn.apache.org/repos/asf/incubator/ofbiz/branches/$\^{Image Removed}{branch-name} ofbiz
4. cd ofbiz
5. svn merge -r ${revision-1}:${revison} http://svn.apache.org/repos/asf/incubatorofbiz/ofbiz-framework/trunk
6. $ svn commit -m "Applied fix from trunk for revision: ${revision}"

Steps for creating a release from a branch:

...

Alternatively you can use the ./tools/mergefromtrunk.sh (or .\tools\mergefromtrunk.bat) tool.