We have two kinds of releases of ArgoUML:
- Development releases.
- Stable releases.
Stable releases are supposed to be better quality-wise and are always advertised to the users community on the main ArgoUML home page and as a news announcement.
Development releases are not supposed to be used by users and are only advertised to users for the purpose of recruiting developers or soliciting help with implementation and test of new features.
To increase the quality of a stable release, a stable release is preceded by a period during which there are a sequence of releases with increased quality standards.
The whole release schedule leading up to a stable release and patched stable release looks like this:
Development Period
A period of one to several months where no special restrictions apply.
During this period we attempt to make one development release per month. The releases are named x.y.z where y is an odd number and z is counting upwards from 1.
The releases are checkpoints where:
- Everything compiles (including the sub-projects).
- The release script works.
- No JUnit tests are failing.
- There are no P1 defects.
The releases are used:
- As reference points when reporting bugs.
- As reference points and convenient downloads for persons working with modules.
First Alpha
This is the enhancement freeze point. All enhancements that are not completed and committed in the main trunk before this point will not be included in the stable release.
The First Alpha release is named x.y.alpha1 or x.y.ALPHA_1 depending on the context. It marks the end of the Development Period and the start of the Alpha Period.
Otherwise it works just like a development release.
Alpha Period
A period of a couple of weeks where special restrictions apply when committing into the main trunk:
- Only bug fixes are allowed in the code.
- Put the number of the DEFECT you are addressing by the commit in the message.
- Test case code can be added. Documentation, web site and other things can be added.
- Exceptions to this are requested to and approved by the Release Responsible before commit.
- During this period we attempt to make at least one Alpha Release each week. The releases are named x.y.alphaz where y is an even number and z is counting upwards from 1 that is the first alpha.
- The purpose of the releases and their use are the same as during the development period.
First Beta
This is the bug fixes freeze point. All enhancements and bug fixes that are not completed and committed in the main trunk before this point will not be included in the stable release. A known problems list could be compiled at this point.
The first beta release is named x.y.beta1 or x.y.BETA_1 depending on the context. It marks the end of the Alpha Period and the start of the Beta Period.
It is the first release candidate for the stable release. Because of this it is required that:
- Everything compiles (including the sub-projects).
- The release script works.
- No JUnit tests are failing.
- There are no P1 or P2 defects.
Otherwise it works just like a development release.
Beta Period
A period of a couple of weeks where the focus is quality assurance. Every developer should strive to:
- Test ArgoUML as thoroughly as possible. Especially the areas that are new or changed since the last release.
- Test and close issues that are resolved to make sure the problem is gone.
- Scrutinize the commits in the main trunk to see that no new bugs are introduced.
Extreme caution applies when committing into the main trunk. Only under the following conditions are commits allowed:
- It is a fix to some DEFECT that was previously fixed but it was found during the verification that the solution was not correct or complete.
- Reopen the DEFECT when the problem is found with a statement of what is still the problem. Put the number of the DEFECT you are addressing by the commit in the message together with the statement of the part of the problem. Resolve the DEFECT as FIXED and update the target milestone with the release name of the next beta.
- Test case code can still be added. Final documentation and web site updates for the release are done.
- All JUnit test cases are run from a cleaned checked out copy at the commit and no problems are found.
- Exceptions to this are requested and approved by the Release Responsible before commit.
If a new problem is found the following needs to be done before committing the solution:
- The problem is registered as a DEFECT.
- The solution is implemented.
- Here the requirement is a high on the quality and low impact of the solution.
- A request is made to the Release Responsible to allow this change.
- This is granted by the Release Responsible.
During the period we attempt to release at least one beta release each week. The releases are named x.y.betaz where y is an even number and z is counting upwards from 1 that is the first beta.
Each release is a release candidate. When we are confident that there are no more problems in this release we make the stable release without code changes compared to the last beta.
Stable Release
This marks the end of the Alpha and Beta Period and the start of the next Development Period.
The release is named x.y where y is an even number.
The release is used:
- By all users.
It can also be used as a development release.
A Stable Patch Release
If we find a serious problem in the stable release we can decide to make a Stable Patch Release.
The following needs to be done before committing the solution:
- The problem is registered as a DEFECT stating that it is a problem in the Stable Release or a previous Stable Patch Release.
- A working branch is created against the release tag of the Stable Release or Stable Patch Release and the solution is implemented in that branch.
- Here the requirement is a high on the quality and low impact of the solution.
- We decide that it is a serious problem and that we are going to do a Stable Patch Release.
- Several developers scrutinize the solution, testing and verifying in the branch of the issue.
- The Release Responsible creates a branch. If this is not the first Stable Patch Release the branch is reused.
- The Release Responsible merges the solution into the branch.
- A Stable Patch Release could contain several issues resolved. In that case they are all merged.
- Several developers scrutinize the merge, testing and verifying in the release branch.
The release is named x.y.z where y is an even number, and z is counting upwards from 1.
The release is used:
- By all users.
After the release is completed the person working with the solution commits his solution also in the main trunk if still applicable there.