Browse files

[builds] Added overview of the release process

  • Loading branch information...
1 parent 2eb9ee8 commit 29b30b10adf5db0a2765784ce73c5457d4b7d003 @spoenemann spoenemann committed on GitHub Feb 2, 2017
Showing with 24 additions and 0 deletions.
  1. +24 −0
@@ -93,6 +93,30 @@ The actual publishing is done on a [Hudson build server](https://hudson.eclipse.
## The Release Process
+#### Overview of the Process
+1. Development phase
+ 1. Work on new features and issues.
+ 2. [Publish milestones](#preparing-milestones-and-releases) as required, e.g. when important new features have been implemented.
+2. Release phase
+ 1. Stop implementing new features, but work on bug fixes.
+ 2. Create a maintenance branch and [publish release candidate milestones](#preparing-milestones-and-releases) as required.
+ 3. [Lift the version number](#lifting-the-version-number) on the `master` branch and start the development phase for the next major/minor release (in parallel to the following steps).
+ 4. Create a test plan and test both old and new features.
+ 5. Prepare release notes.
+ 6. Merge the bug fixes into the `master` branch.
+ 7. [Publish the release](#preparing-milestones-and-releases).
+ 8. Create and push git tags.
+ 9. [Close the GitHub milestone](#github-milestones) and create new milestones.
+3. Maintenance phase
+ 1. [Lift the version number](#lifting-the-version-number) on the maintenance branch.
+ 2. Work on bug fixes on the maintenance branch.
+ 3. Merge the bug fixes into the `master` branch.
+ 4. [Publish a service release](#preparing-milestones-and-releases).
+ 5. Create and push git tags.
+ 6. [Close the GitHub milestone](#github-milestones).
+ 7. If necessary, create a new GitHub milestone and repeat the maintenance phase.
The `master` branch on each repository is the development stream for the next major or minor release. There are also one or more development streams for service releases, which are named `maintenance_«minorversion»`, where `«minorversion»` is the version number without the third segment (e.g. `maintenance_2.12`).
When major or minor releases are done, there should be a time period of at least one week when only important fixes are added to the code base to be released. This is achieved by creating the maintenance branch for that release and committing the fixes directly to that branch. The maintenance branch is merged back into `master` just before the actual release is done so the fixes are available there, too. After the release is done, the service release version is increased on the maintenance branch. Furthermore, a "pseudo-merge" to `master` should be made afterwards so the following bug fixes can be merged later on without including the version change. The necessary git command line flag for this kind of merging is `-s ours`.

0 comments on commit 29b30b1

Please sign in to comment.