Skip to content

Add the documentation for the release model #6297

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 17, 2019

Conversation

anatoliykmetyuk
Copy link
Contributor

No description provided.

@@ -1,17 +0,0 @@
---
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have several links to this page on the dotty website (e.g. release blog posts).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make a redirect from that url to the new one?

Copy link
Contributor

@biboudis biboudis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

# Model
The easiest way to produce a release of a GitHub-based open-source software is to tag the most recent commit on the `master` with the version number at regular intervals of time or once a previously agreed milestone is reached. However, this approach to releasing would rest on the assumption that each commit at the `master` branch can potentially be made into a release. We cannot provide the release-grade quality guarantees for each of the `master` commits, though.

This is why, in Dotty, we are using the above method of naive releasing-by-tagging to mark release candidates (RC’s) and not the stable releases. The stable releases are also marked by a tag, but we have a procedure to assure their quality.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

revised grammatically

Consequently, in Dotty, we are using the method above--releasing-by-tagging--to mark release candidates (RC’s) and not the stable releases.


An RC is promoted to a stable release in one release cycle after its creation. The idea is that this way, we have one release cycle's time to examine the release candidate and find critical issues which cannot be allowed into a stable release.

If such issues are found, their fixes end up on a separate branch dedicated to that release. In one release cycle after the RC creation, the RC, along with all its afterthought fixes, is promoted to a stable release by means of tagging it.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

afterthought -> subsequent (cannot be used as adjective)

If such issues are found, their fixes end up on a separate branch dedicated to that release. In one release cycle after the RC creation, the RC, along with all its afterthought fixes, is promoted to a stable release by means of tagging it.

# Example
Say we want to release the 0.14.0 version. The process to do so (at a glance).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is the following: or Next we describe the process...


## At the Dotty Repo
1. Tag the latest `master` commit as `0.14.0-RC1`. This commit is the release candidate for the `0.14.0` version.
2. Create a branch from that commit called `0.14.x`. This branch is intended to host the afterthought fixes to the RC for the issues that cannot be allowed in the `0.14.0` stable release.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

afterthought -> subsequent

@anatoliykmetyuk
Copy link
Contributor Author

Thanks for the review @biboudis, I've addressed your points.

@anatoliykmetyuk anatoliykmetyuk merged commit 874a203 into scala:master Apr 17, 2019
@anatoliykmetyuk anatoliykmetyuk deleted the release-procedure-doc branch April 17, 2019 11:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants