Read the Onboarding Guide for Release Managers! |
IMPORTANT: This process did not work for the last release (0.92.0). I created an issue to fix it, see #1667).
To provide a proper overview of what has changed within the current release, we need to update file RELEASE_NOTES.md in our release branch (rel/VERSION ).
Therefore it is required to perform the following steps.
# Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). # [x.yy.z] <GENERATED RELEASE NOTES> |
Update the current version in the issue template for bug reports here.
- type: dropdown attributes: label: Apache StreamPipes version description: What Apache StreamPipes version are you using? multiple: false options: - "0.70.0" # change to new release version - "dev (current development state)" - "Other StreamPipes version (please specify below)" |
It is recommended to use a clean repository for release preparation to ensure there are no unexpected local files in the source release. |
Make sure that you are in the branch rel/VERSION that you created earlier
First, set sp.version in the Maven archetypes to the upcoming release version of StreamPipes:
# In all subdirectories of archetypes, open the pom.xml file in src/main/resources/archetype-resources and set the sp.version property to the upcoming version (e.g., 0.69.0) |
Update the UI version manually to the upcoming version:
# Update the version in ui/package.json # Update the version in ui/package-lock.json (Be careful, this file contains two places with SNAPSHOT). |
Update the Python client version manually to the upcoming version:
# Update the version in streampipes-client-python/streampipes/endpoint/api/version.py |
Use the update version script to change version of the installer (directory: installer)
# change version to next release version ./upgrade_versions.sh OLD_VERSION NEW_RELEASE_VERSION # ./upgrade_versions.sh 0.68.0 0.69.0 # Commit and push these changes to rel/VERSION |
Now it's time to perform the Maven release!
Make sure to checkout a clean copy of incubator-streampipes and perform the following. Make sure you do this from the rel/VERSION branch!
mvn release:prepare -DautoVersionSubmodules=true -Papache-release |
The release plugin will ask you a few things:
The version we want to release as (It will suggest the version you get by omitting the -SNAPSHOT suffix)
The name of the tag the release commit will be tagged with in the SCM (Name it release/{release-version} (e.g., release/0.69.0 )
The next development version (The version present in the pom after the release) (e.g., 0.69.1-SNAPSHOT, use the next patch version and not the new minor version in dev)
Once this is finished, check that everything is correct: There should be a new tag release/version (e.g., release/0.69.0) which doesn't have any SNAPSHOT dependencies. In addition, your rel/VERSION branch should be increased to the next patch version.
Great! So the next step is to actually perform the release and stage the artifacts to the ASF Nexus. The command you need to run is:
mvn release:perform -DreleaseProfiles=apache-release |
Uploading the artifacts to the ASF Nexus might take some time. Once it is finished, go to https://repository.apache.org, log in with your Apache credentials, go to "Staging Repositories" and search for "streampipes".
There should be one item in the list containing the just uploaded files. Click on "Close" and enter a message (e.g., Close StreamPipes release VERSION) and then you are done on the Maven side!
Important! Only when there was an error in the release. If this is the case, the maven release can be reverted with the following commands:
# Drop artifacts in Nexus repository - Go to https://repository.apache.org and login - Go to "Staging Repositories" and search for "streampipes" - There should be one item in the list containing the just uploaded files - Click on "Drop" and enter a message # Delete git tags, both locally and remote - git tag -d release/#RELEASE_VERSION (e.g. git tag -d release/0.69.0) - git push --delete origin release/#RELEASE_VERSION (e.g. git push --delete origin release/0.69.0) # Rollback maven version - mvn versions:set -DnewVersion=#OLD_DEVELOPMENT_VERSION (e.g. mvn versions:set -DnewVersion=0.60.0-SNAPSHOT - Check that the version was changed correctly in all pom.xml files - mvn versions:commit # Commit changes in git # Now the release process can be started again |
The final step is to upload the source release artifacts to the Apache SVN:
# Create a new rc folder in the SVN (https://dist.apache.org/repos/dist/dev/streampipes) # Create a new directory for the version (e.g., 0.69.0) and add release candidate (which is increased for every failed release), e.g., rc1. # The folder structure should look like this: - 0.69.0 - rc1 # Copy the following files into this folder (they can be found in streampipes/target/checkout/target: - RELEASE_NOTES.md - RELEASE_VALIDATION.md - README.md - The zip file (apache-streampipes-VERSION-source-release.zip) - The asc file (apache-streampipes-VERSION-source-release.zip.asc) - The sha512 file (apache-streampipes-VERSION-source-release.zip.sha512) # Commit these changes to SVN. |
Great! StreamPipes is ready for release voting.
Now comes the best part: You're ready to send the VOTE mail to the developer list!
TO: |
TO: |
After 72 hours, the vote can be closed. Sometimes it might be worth to wait a little longer to allow all PMC members to vote accordingly. If votes are missing, you can also directly approach people from the PMC and ask for their vote.
Send the following mail to the dev list to announce the results:
TO: The vote PASSES with X votes +1 (X binding/Y non-binding) and no -1.
|