Release 0.63.0
We are releasing a new version, this issue will keep track of the progress between the first release candidate (27th of this month, march) to the final release (3rd of next month, april).
After the 27th of this month we start the release process that ends 7 days after, during that period we enter a Feature Freeze. While in the Feature Freeze we do not merge new features or non critical or important bug fixes. Fixes for bugs created by this release will be prioritized.
This month we are shifting the normal dates by 7 days, it's an exceptional case as announced here. Next release will be back to the normal release dates.
For any regression, open a new issue and link to this one.
Before Release - Preparation - 1 business day before the day 27th
- [x] Create the issue to track the release progress
- [x] Define the highlights from release PRs as suggestion to be included on Blog Post
- [x] Talk to the Marketing Team about the Blog Post release
- [x] Talk to the Documentation Team about the Docs release
- [x] Sync translations from LingoHub
Release Candidate 1 - On the 27th
- [x] Delete branch
release-candidate
- [x] Create branch
release-candidate based on develop
- [x] On branch
release-candidate run npm run release and follow the steps
- [x] Publish the branch and the generated tag
- [x] Edit the tag on GitHub and paste the generated History removing the version from the first line and mark the checkbox This is a pre-release
- [x] Ensure the build is passing on CircleCI
- [x] Ensure the build is passing on Docker Hub
Release Candidate 2 - On the 29th
- [x] Merge
develop into release-candidate branch
- [x] On branch
release-candidate run npm run release and follow the steps
- [x] Publish the branch and the generated tag
- [x] Edit the tag on GitHub and paste the generated History removing the version from the first line and mark the checkbox This is a pre-release
- [x] Ensure the build is passing on CircleCI
- [x] Ensure the build is passing on Docker Hub
Release Candidate 3 - On the 3rd
- [x] Merge
develop into release-candidate branch
- [x] On branch
release-candidate run npm run release and follow the steps
- [x] Publish the branch and the generated tag
- [x] Edit the tag on GitHub and paste the generated History removing the version from the first line and mark the checkbox This is a pre-release
- [x] Ensure the build is passing on CircleCI
- [x] Ensure the build is passing on Docker Hub
Final Release - On the 3rd
- [x] Merge
develop into release-candidate branch
- [x] Create a new branch
release-0.63.0 based on release-candidate
- [x] On branch
release-0.63.0 run npm run release and follow the steps TODO: fix the history
- [x] Publish only the branch
- [x] Draft a new release on GitHub
- [x] Enter tag version as 0.63.0
- [x] Select target master
- [x] Enter release title as 0.63.0
- [x] Paste the history removing the version from the first line
- [x] Save as draft
- [x] Create a PR from the branch
release-0.63.0 with the same history from the tag/release
- [x] Ensure the build is passing on CircleCI
- [x] Ensure the build is passing on Docker Hub
- [x] When build is passing ask for approval
- [x] When approved merge it!
- [x] When merged edit the release/tag and publish it
After Release - Conclusion - 1 business day after the 3rd
- [x] Check if related issues was closed
- [x] Check if related issues was assigned to the correct milestone
- [x] Check with the Marketing Team about the Blog Post release
- [x] Check with the Documentation Team about the Docs release
- [x] Create a Sync PR to merge back master to develop
- [x] Merge Sync PR
Most helpful comment
The most fitting question to your very broad and not really answerable question would be the Debian one: when it's ready.
Cheers
Thomas