CEP 8 - Conda Release Schedule

[kenodegard]

Description

Define a release schedule that is better than today's ad hoc releases by borrowing ideas from Python, Django, and GitLab.

Objectives

• regular releases
  • better feature planning
  • commit to a deprecation policy
    • deprecating old features (see CEP 9: Conda Deprecation Schedule #27)
    • deprecating Python versions (see CEP 10: Conda Version Support #25)
• option to do hotfix/bugfix/security releases when needed
• a consistent and predictable release cadence
  • some users desire slower updates than others, especially multi-user installs
  • stability promise (?), e.g. last release of a quarter is bugfix-only
• trivial and obvious release management
  • scale the responsibility to include community members
• can the same schedule be used for conda-build
  • should conda-build use the same versioning as conda?

[carterbox]

With this new versioning scheme anything can change at a MINOR release and only patches/bug fixes happen a MICRO? The only way to know about upcoming breaking changes is via changelogs or deprecation messages?

[kenodegard]

@carterbox Correct but we are also working on defining a new deprecation policy in a separate CEP (see #27).

The objective of moving to CalVer is to remove the guesswork on maintainers of deciding if certain changes warrant a MAJOR, MINOR, or MICRO increment. So yes, new features (e.g. new subcommands, new arguments, new APIs) could occur in any release (but most likely in a regularly scheduled MINOR release) and would be announced in the changelog and in other communications (e.g. blog posts). Overall introducing new features shouldn't carry that great of a risk.

Per the ideas proposed in #27, deprecations/breaking changes are intended to be handled more graciously than they have in the past. Features would be marked as pending deprecation at any point but would only be deprecated and eventually removed after a number of regular (not optional/hotfix) releases.

[travishathaway]

Looking good. Just some grammar related changes and other suggestions for improvements.

[jezdez]

Thank you all for the thoughtfulness put into this!

[jezdez]

@conda-incubator/steering

This PR falls under the Enhancement Proposal Approval policy of the conda governance policy, please vote and/or comment on this PR.

This PR needs 60% of the Steering Council to vote yea to pass.

To vote please leave Approve (yea) or Request Changes (nay) pull request reviews.

If you would like changes to the current language please leave a comment (in the PR) or push to this branch.

This vote will end on 2022-08-12.

[ocefpaf]

Minor comment. And what-if scenario: suppose folks are changing jobs and there isn't anyone to issue an expected release? Is this a promise to users and they'll feel that something is amiss if a release is skipped? Or is this only some guidelines and skipping one or another will be communicated as "OK."

Does that make sense? Sorry, I'm trying to put a corporate hat of someone expecting a release that won't come. But I'm terrible at playing corporate.

[kenodegard]

This is intended to be a release schedule promise held by the conda org to our users. Ideally, releases should be a shared community responsibility to encourage knowledge sharing (should probably create a release subteam that can cater to this).

[msarahan]

Is there any kind of contingency for if no changes have occurred since the last release? This document makes me think that a release will happen no matter what, every 2 months. Of course, it's silly to release identical code with a new version, but we don't explicitly preclude that possibility.

In that vein, is there a time window where changes are expected to make it into the next release? What are the code cutoffs for each of the various cycles? Does that belong in this doc or elsewhere?

[jezdez]

@msarahan Good point, that seems like a reasonable and likely scenario (in the future), I'd suggest adding a point like:

In case no or few significant changes have been made since the last release, the conda maintainer team may decide to skip a regular release, as long as the decision is made public and documented in the changelog.

[ocefpaf]

This is intended to be a release schedule promise held by the conda org to our users.

That is my concern and a promise that can be broken by something as silly as "there isn't someone available right now for a release" or "there is no change in the code base" is not something that will build trust from users.

In case no or few significant changes have been made since the last release, the conda maintainer team may decide to skip a regular release, as long as the decision is made public and documented in the changelog.

That works for me @jezdez. Thanks!

[msarahan]

Is it worth discussing my second point?

In that vein, is there a time window where changes are expected to make it into the next release? What are the code cutoffs for each of the various cycles? Does that belong in this doc or elsewhere?

if you’d rather not get into those weeds, I understand.

[kenodegard]

@msarahan Oh sorry, I don't have a strong opinion on this one. I'd say that's a decision the release manager(s) get to make? Obviously large changes shouldn't be crammed in last minute but small fixes (e.g. typos and other minor corrections) could be included without too much trouble.

[jezdez]

@conda-incubator/steering

This vote falls under the Enhancement Proposal Approval policy of the conda governance policy, please vote and/or comment on this PR.

This vote needs 60% of the Steering Council to vote yea to pass.

This vote presently has 6, and needs 4 more for quorum.

It is proposed that this vote will time out and be evaluated with the current votes in 7 days, on 2022-08-19.

To vote please leave Approve (yea) or Request Changes (nay) reviews.

[chenghlee]

Voting Results

This was a standard, non-timed-out vote.

• Among Steering Council members there are 10 "yes", 0 "no", and no abstentions.
• No Emeritus Steering member voted.

This vote has reached quorum (10 + 0 = 10 which is at least 60% of 16).

It has also passed since it recorded 10 "yes" votes and 0 "no" votes giving 10/10 which is greater than 60% of 15.

It should be noted that a request for change was recorded in the pull request about minor implementation details that do not invalidate the previous votes. The author made the requested change.