"Release process" blogpost: Explain that we no longer adhere to a fixed four-month schedule for feature freeze #2189
Conversation
…ed four-month schedule for feature freeze
|
Once the build has completed, you can preview your PR at this URL: https://julialang.netlify.app/previews/PR2189/ in ~15 minutes |
|
Hat-tip to the Discourse user (https://discourse.julialang.org/t/julia-1-12-feature-freeze-wednesday-january-8-2025/122902/2?u=dilumaluthge) that noticed this outdated content. |
|
cc: @felixcremer |
…with some updated information
|
Okay, I think I've found and fixed all the relevant locations. |
| @@ -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.~~ | |||
There was a problem hiding this comment.
Is it necessary to keep the old text that was probably never applied anyway?
There was a problem hiding this comment.
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]
There was a problem hiding this comment.
I think that would be better.
Since this is a blogpost, it felt kind of weird to delete the content wholesale, so for posterity I struckthrough the old content, and then I added the new content, preceded by the phrase
Edit (November 2024)to make clear the new nature of the content.