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 issues.
The releases are used:
As reference points when reporting bugs.
As reference points when verifying issues.
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 issues.
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.
Verify issues that are resolved.
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 have reached the point where no more issues are verified
and 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:
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:
After the release is completed the person working with the solution
commits his solution also in the main trunk if still applicable there.
