Skip to content
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.

Sign up for GitHub

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

Jump to bottom

"Release process" blogpost: Explain that we no longer adhere to a fixed four-month schedule for feature freeze #2189

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
+9 −4
Open

"Release process" blogpost: Explain that we no longer adhere to a fixed four-month schedule for feature freeze #2189

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
4e6b3b2
"Release process" blogpost: Explain that we no longer adhere to a fix…
DilumAluthge Nov 21, 2024
1b8bd60
Make another small edit
DilumAluthge Nov 21, 2024
899364f
Strikethrough two additional paragraphs, and add an "edit" paragraph …
DilumAluthge Nov 21, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 9 additions & 4 deletions blog/2019/08/release-process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,8 @@ This information is collected from a small set of posts on [discourse](https://d

- Minor releases are also where significant refactorings of internals go, since we should only be refactoring to the extent that is necessary for fixing bugs in patch releases. This means that if you're relying on some internal Julia stuff that's not public, your code might break in a minor release. This is allowed according to SemVer since the change isn't to a public API—so technically it can break at any time; but we will avoid this in patch releases, so minor releases will be where you have to watch out if you rely on internals somehow.

- Minor releases are branched every **four months**, which means that there are three minor releases per year. The rate is controlled by doing timed features freezes for minor releases: every four months, we announce on discourse that the current development version is about to feature freeze (with about two weeks notice); then on the freeze date, we branch a `release-1.3` branch for the minor release and after that no more feature development is allowed on that branch, from which the release will be tagged. More on that process below.
- ~~Minor releases are branched every **four months**, which means that there are three minor releases per year. The rate is controlled by doing timed features freezes for minor releases: every four months, we announce on discourse that the current development version is about to feature freeze (with about two weeks notice); then on the freeze date, we branch a `release-1.3` branch for the minor release and after that no more feature development is allowed on that branch, from which the release will be tagged. More on that process below.~~
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it necessary to keep the old text that was probably never applied anyway?

Copy link
Member Author

Choose a reason for hiding this comment

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

My thinking was that because this is a blogpost, it would be weird to delete content. So my original plan was to strikethrough the original content.

Now, I'm actually wondering if we should just preserve the original blogpost as-is, and just make a new page (either in the Julia devdocs, or somewhere in the Julia website) with an updated version of this content. And then, at the top of this blog post, just add a note that says:

This is a historical blog post that is now outdated. The updated version of this content is maintained here: [link]

- Edit (November 2024): The process of a new minor release begins with the feature freeze. Periodically, we announce on Discourse that the current development version is about to feature freeze (with some amount of advance notice); then on the freeze date, we branch a `release-1.x` branch for the `1.x` minor release and after that no more feature development is allowed on that branch, from which the release will be tagged. More on that process below.

## Major releases

Expand Down Expand Up @@ -84,7 +85,7 @@ If these two criteria are satisfied by a new LTS branch, then users in the "low

We've discussed what various kinds of releases mean and what types of changes can go into them, but we haven't talked much about how a release actually gets made. In this section I'll outline how we go from working on features on the `master` branch to tagging a final version of the release and after that making patches of that release. I will use the word “bugs” to refer to both bugs in the usual sense of incorrect code but also “performance bugs”—i.e. code that runs slower than we consider acceptable. In Julia, performance is a vital property and we often consider performance issues to be blocking bugs. The following is an outline of the sequence of events surrounding a `x.y.0` minor release:

- **Development** (4 months)
- **Development** (~~4 months~~ time period varies)
- on the `master` branch
- develop new features, fix bugs, etc.
- tag `x.y.0-alpha` (optional)
Expand Down Expand Up @@ -115,9 +116,13 @@ We've discussed what various kinds of releases mean and what types of changes ca

You can tell just from a glance that this might be a long and unpredictable process. In particular, the stabilization phase can take a highly variable amount of time—from a few weeks to months. This creates a tension between assuring quality and wanting to have a predictable rate of releases. On the one hand, we do not want to rush the release candidate process since it is very much what ensures that each Julia release has the quality and stability that you've come to expect. On the other hand, we don't want the overall rate of releases to be held hostage to the vagaries of how long debugging takes—and we all know that can be a long, painstaking process for any project, and especially for something as complex as a programming language.

We resolve the tension between assuring the quality of releases and keeping a predictable release rate by overlapping the stabilization of one release with the development of the next release. The development phase of each release is time-boxed at four months and the development phase of `x.(y+1)` starts as soon as the development phase for `x.y` is over. Come rain or shine we have a new feature freeze every four months: we pick a day and you’ve got to get your features merged by that day. If new features aren't merged, they’re not going in the release. But that's ok, they'll go in the next one. This approach also means that `master` is always open for new features rather than being frozen during the stabilization period.
~~We resolve the tension between assuring the quality of releases and keeping a predictable release rate by overlapping the stabilization of one release with the development of the next release. The development phase of each release is time-boxed at four months and the development phase of `x.(y+1)` starts as soon as the development phase for `x.y` is over. Come rain or shine we have a new feature freeze every four months: we pick a day and you’ve got to get your features merged by that day. If new features aren't merged, they’re not going in the release. But that's ok, they'll go in the next one. This approach also means that `master` is always open for new features rather than being frozen during the stabilization period.~~

As a result of overlapping development and stabilization, if release candidate process takes an unusually long time, the final release of `x.y.0` might happen at around the same time as the feature freeze for `x.(y+1).0`. This happened with `1.2.0` and `1.3.0`, for example. There was some confusion and consternation expressed about this on discourse, but that's the inevitable side effect of keeping a predictable release rate. The `1.2` stabilization phase was an unusually long one, which happens sometimes. We're always examining our process and thinking about how to improve it. One change which might help is running PkgEval more often in a completely automated fashion so that we know earlier when a change during development breaks packages. Running PkgEval early and often makes it easier to narrow down which change caused the breakage. If anyone wants to get involved and help make the Julia release process better, helping with PkgEval would be a really high impact piece of work which does not require deep technical knowledge.
~~As a result of overlapping development and stabilization, if release candidate process takes an unusually long time, the final release of `x.y.0` might happen at around the same time as the feature freeze for `x.(y+1).0`. This happened with `1.2.0` and `1.3.0`, for example. There was some confusion and consternation expressed about this on discourse, but that's the inevitable side effect of keeping a predictable release rate. The `1.2` stabilization phase was an unusually long one, which happens sometimes.~~

Edit (November 2024): Much of the previous two paragraphs is not currently true. For the past several releases, we have not overlapped the stabilization of one release with the development of the next release. However, some details are still correct. In particular, the following is still true. We still announce a feature freeze date on Discourse: we pick a day and you’ve got to get your features merged by that day. If new features aren't merged, they’re not going in the release. But that's ok, they'll go in the next one. This approach also means that `master` is always open for new features rather than being frozen during the stabilization period.

We're always examining our process and thinking about how to improve it. One change which might help is running PkgEval more often in a completely automated fashion so that we know earlier when a change during development breaks packages. Running PkgEval early and often makes it easier to narrow down which change caused the breakage. If anyone wants to get involved and help make the Julia release process better, helping with PkgEval would be a really high impact piece of work which does not require deep technical knowledge.

One point to note, since people are sometimes confused by this: feature freeze only affects new functionality—bugs can be fixed at any point on any branch. It is never too late for a bug fix. The only time where a bug fix will not go on a release branch is if it is no longer maintained. Even then, if someone else wants to fix a bug and go through the process of making a new release, we will gladly help, we just won’t do it ourselves.

Expand Down