This here is the release process for snapcraft for future reference and potential process improvement:
- Compile list of items to work on from the roadmap items depending on allocated time of the team.
- Create the milestone with the list of items to work on with team members assigned to each item.
- Create a documentation item (if non existent) before each PR.
- Create PRs for each issue in the created milestone, for which each would close a certain issue OR be manually closed if it is a stand-alone documentation item or research work.
- Create an SRU bug
- 3 days before the end of cycle, create the changelog PR.
- Run all the relevant autopkgtests against the changelog PR.
- Commit the changelog PR, effectively freezing new code.
- Create an annotated tag for the commit related to the changelog PR.
- Start drafting the release notes on the release tag
- Ensure deprecation notices are published, and web team are set to deploy.
-
snapcraft release
tobeta
- Run tests against
beta
- Create a debsource package and
dput
toxenial
- Forward port snapcraft to future supported and the development release and
dput
there as well. - Look at SRU wiki to find out who is on rotation and ping the person listed as the contact for the day.
- Create a python source package and push to PyPI
- Update the homebrew formula
-
snapcraft release
tocandidate
- Make a Call for testing on the forum
- Test on: homebrew, docker, deb for ubuntu releases, snap; on amd64, armhf and arm64 where relevant.
- Contact the SRU team on #ubuntu-release to make the migration to
<release>-updates
-
snapcraft release
tostable
- Close the milestone
- Mark the affected bugs on launchpad in the milesone as
Fix Released
- Announce release on the forum
- Announce the release on the Snapcraft Twitter, Facebook, and Google Plus accounts