The release procedure is quite straightforward and simple. Once a release has been done, the team meets to plan which features has to be implemented for the next version. Once we agree on this, we set a more or less fixed date in which we should release the next stable version. Once we are around said date, we will release the next version whenever we feel that Portus is ready (while taking into account other stuff like documentation, etc.).
First of all, we follow this steps on the Github repository:
- Create a new branch name
vX.Y, being X.Y the new version.
- For a small period of time, this branch will receive last-time updates/fixes, like for example reviewing the gems in the Gemfile.lock.
- Update the
VERSIONfile (in that branch).
- Check whether the
CHANGELOG.mdfile actually contains all the changes and that is not badly formatted.
- Push a commit with the message “Bump version X.Y.Z”.
- Tag source code as X.Y.Z.
With the steps above, we have released the new stable release on Github. However, in SUSE we also make use of the Open Build Service. The containers team at SUSE usually works in the Virtualization:containers project, but for Portus we decided to work on three different subprojects:
- Virtualization:containers:Portus, which contains an RPM with the latest commit on the
- Virtualization:containers:Portus:2.0, containing the latest stable release (2.0).
- Virtualization:containers:Portus:2.0-git, containing the latest commit on the stable branch (v2.0).
New minor and major releases will have their own subproject, which will follow the same rationale as for the ones that we have for the 2.0 release. Also note that the RPMs produced by these three different projects are the ones that will also be used in the official Docker images. You can find more information about these pages here.
To handle the release process as it has been described, we use some custom
scripts and rake tasks. In particular, the rake tasks are
release:bump. The other scripts being used can be found