Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Capra/PreparingForRelease"
(→Version numbers) |
|||
| Line 1: | Line 1: | ||
| − | The general workflow for releases is as follows | + | The general workflow for releases is as follows: |
# Create a local branch for the release that contains all commits that should be part of the release. | # Create a local branch for the release that contains all commits that should be part of the release. | ||
# Create the release using the procedure outlined below. | # Create the release using the procedure outlined below. | ||
# Build the release and publish it using CI. | # Build the release and publish it using CI. | ||
| + | |||
| + | == Create a branch for the release == | ||
| + | |||
| + | We follow the basic [https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow gitflow] workflow for development, including releases. | ||
| + | |||
| + | # Make sure that all commits that should be included in the release are present in the develop branch. If not, please cherry-pick them into <code>develop</code> or rebase develop on the relevant feature branches. | ||
| + | # Create a release branch from <code>develop</code> using the target release version: | ||
| + | git checkout develop | ||
| + | git checkout -b release/0.7.0 | ||
| + | # All fixes for the release should then go into the release branch. Once the release has been performed, this branch can be merged back into master and develop can be rebased on it. | ||
== Create the release == | == Create the release == | ||
Revision as of 05:58, 30 April 2019
The general workflow for releases is as follows:
- Create a local branch for the release that contains all commits that should be part of the release.
- Create the release using the procedure outlined below.
- Build the release and publish it using CI.
Contents
Create a branch for the release
We follow the basic gitflow workflow for development, including releases.
- Make sure that all commits that should be included in the release are present in the develop branch. If not, please cherry-pick them into
developor rebase develop on the relevant feature branches. - Create a release branch from
developusing the target release version:
git checkout develop git checkout -b release/0.7.0
- All fixes for the release should then go into the release branch. Once the release has been performed, this branch can be merged back into master and develop can be rebased on it.
Create the release
Eclipse Capra is using the unleash-maven plugin to prepare for releases. The plugin switches the version numbers to a release version for all pom.xml and metadata files (MANIFEST.MF, feature.xml, etc.), creates a tag for the release and then switches back to a development version. All changes are automatically committed to git.
The tool should be run locally as:
mvn unleash:perform-tycho -Dunleash.developmentVersion=0.7.0-SNAPSHOT -Dunleash.releaseVersion=0.7.0.RC_20190429
Make sure to have ssh-agent running if using git with public/private key. Otherwise, please see the unleash-maven documentation for details on how to provide credentials.
It is also important to note that Maven version 3.3.9 or higher. Please make sure that this version is installed.
Version numbers
The example above shows how to create a Release Candidate. Therefore, the development version is set to the same version as before. Usually, for a full release, we would increment the minor version like this:
mvn unleash:perform-tycho -Dunleash.developmentVersion=0.7.1-SNAPSHOT -Dunleash.releaseVersion=0.7.0
In general, we follow the Version_Numbering prescribed by Eclipse. If the version numbering does not follow the prescribed format, an org.eclipse.tycho.versions.engine.IllegalVersionChangeException will be thrown and Maven will stop processing.
Build and publish the release
Later, the tag can be used in CI to create the build and publish it to the download area.