Creating a new Nebula Release
This page describes how to create a new release.
Nebula uses the major.minor.service version semantics.
A minor release is a new release without an API break. The Minor Release versioning updates the second number, e.g., 2.7.0 -> 2.8.0.
Announce your plan on the mailing list and describe that a new release is imminent. The project lead will be involved in some of the steps. The date of the release will be no later than 7 days after the announcement.
The project lead defines the service release here https://projects.eclipse.org/projects/technology.nebula.
For a minor release, we must add a new milestone after or before a release is released. Milestones are the numbers of the next release.
In Github press the "New Milestone" button:
Enter the milestone information
Create a release bug that you can use to commit your changes to the branch.
Summary: Nebula x.x.x releng
Milestone: x.x.x
Press this link to create the bug
All the bugs that are going to be part of this release must have their milestones set in Github. All other bugs must move to the next milestone.
There is a job that will push the latest snapshot to the release directory. The release directory has this form:
https://download.eclipse.org/nebula/releases/x.x.x/
The build configuration needs to contain your version number in the dropdown list.
Add your version number if it does not exist. Remove all the older version numbers to make sure these directories are never overwritten.
The release version number must be updated to the new version number. Don't forget the pom.xml and the version number in the update site. For a Service Release
You have to push this version to the master branch first and then cherry-pick it in the release branch later. For a Minor Release
You have to push this version to the master branch. This will trigger the build.
releng/org.eclipse.nebula.updatesite/category.xml
releng/org.eclipse.nebula.feature/feature.xml
releng/org.eclipse.nebula.feature/pom.xml
Run the release job. This will create the release directory from the latest build.
The build will be available here:
https://download.eclipse.org/nebula/releases/x.x.x/
You have to make sure that no other master build has executed in the meantime. The build is running if others make new PR against master or if someone pushes/merges to master. It is not likely that this will happen but in case it does:
You can add a comment to your PR "retest this please" to trigger a new build from the PR.
Please let the list know that the release is ready for test:
If you have imported the psf file then you have the website checked out. The Nebula website is a separate project that uses Gerrit. You may add the PL and others as reviewers, or submit directly if you are confident. Every push to this website will be live within 5 minutes after submitting through Gerrit. Not much can break because we can always revert/resubmit. What needs to be done
Basically you have to take care that the downloads page is up to date. This might involve creating and updating the Javadoc.
Just copy an existing release directory, make the obvious changes, edit the main downloads.php page, and you are done.
The Javadoc can be updated with the Javadoc Ant script. After the Javadoc has been generated, replace it in the release directory and push to Gerrit.
After the release is live, it needs to be placed in GitHub:
https://github.com/eclipse/nebula/releases
Take a look at existing releases and duplicate this for the new release.
https://github.com/eclipse/nebula/releases/new
During this process, you can make a Tag of the working branch.
After the release is created, you may delete the PR and the working branch.
After the release is live, the GitHub milestone needs to be closed.
https://github.com/eclipse/nebula/milestones
Take a look at the existing milestones and duplicate this for the new milestone
Issues that did not make the cut must be moved to the new milestone.
You made it! Congratulations. Please announce the new release on the mailing list:
Do not forget to close the pull request and delete the branch on GitHub.
A Service Release is intended to fix a bug in the minor release. Service releases have the third number of the release set, e.g., 2.7.0 -> 2.7.1. To create a new Nebula Service Release, follow the steps below. To avoid unneeded risks, you must cherry-pick your changes on top of the latest released tag.
Before you start, open a new workspace and import this project set via Import/Team/Team Project Set.
- Announce Service Release on Mailing List
- Create Service Release in Project Administration
- Add GitHub Artifacts for Service Release
- Create Release Bug
- Classify Bugs
- Update Version in Main Feature
- Cherry-Pick Changes on Working Branch
- Create Pull Request in GitHub
- Update Build Configuration
- Promote Build Candidate
- Announce and Test Candidate
- Update Website
- Add Release to GitHub
- Close GitHub Milestone
- Update NAN
- Announce Success