CEP 10: Conda Version Support

[travishathaway]

This CEP aims to provide a clear support windows for the conda package manager. This is still a work in progress and everyone is invited to comment on this PR with suggestions as we refine and develop this policy.

[jakirkham]

Curious, what statistics have we already looked at?

[travishathaway]

@jezdez found a model we could potentially follow: https://devguide.python.org/versions/

We should definitely have a nice graph included in this CEP 😉

[brettcannon]

I'm happy to answer any questions folks might have about Python's support policy.

[travishathaway]

@jakirkham, we have download/user agent statistics for anaconda.org.

[travishathaway]

The following graph gives a pretty good overview of current version usage. The data used come from access logs to anaconda.org from 2022-11-10 and 2022-12-09. It show the cumulative summation of version usage from oldest to newest.

This graph shows the percentage of conda users per version based on the same access log data:

[travishathaway]

I learned something interesting today about pip:

The latest version of the pip is the only supported version, previous versions should be considered unsupported. Users are encouraged to make regular updates to their version of pip in order to remain supported.

source: https://pip.pypa.io/en/latest/development/release-process/#supported-versions

I'm not sure such a release schedule would work for conda, but I'd be interested to hear to some other opinions. So far, I'm leaning towards something like Python has. Basically, we would only support the last four or five releases with categories for "bugfix" and "security" level fixes. Considering releases come out about every two months, this would give our users eight to 10 months of using an officially supported version of conda.

[brettcannon]

Selfishly, from a tooling perspective, the shorter the better as it means we don't have to maintain support for buggy conda versions for as long. 😁 But I think it really comes down to how much will it cost to backport bug fixes to versions that are still under the support SLA, and are you willing to pay that cost? Are you okay backporting across potentially e.g. 5 maintenance branches when a fix in main comes in? From a CPython perspective, having to maintain main and up to two more bugfix branches has a definite cost, and that's with tooling to help automate the backports.

[kenodegard]

Since we don't backport patches to older versions of conda I'd argue that we don't currently "support" anything beyond the most recent release. It's rather the rest of the infrastructure (e.g., anaconda.org, conda-build, etc.) that supports a longer conda tail. Will this proposal change this? Will this proposal dictate that bug fixes will need to be backported to all supported versions?

Enterprise users are fickle and often have IT policies that don't allow for frequent updates. It wouldn't be unreasonable for these users to update once or twice a year. Is this something we care about in the first place? Since our release policy dictates bi-monthly/six releases per year, the deprecation policy was written to slow down the window of forced updates. Perhaps we could designate the deprecation releases (the March and September releases) as also being LTS releases that are supported longer than the rest of our releases? Something like normal releases are supported until the next release and LTS releases are supported (with bugfix patching) for a year? This would mean that at any one point in time we'd be supporting at most 3 versions of conda.

[rolweber]

Does the release frequency of Miniconda play a role in this?
The latest I can get from https://repo.anaconda.com/miniconda/ currently is 4.12.0.
Is there another simple way to bootstrap conda with a newer version?

[travishathaway]

@rolweber, check out Miniforge. Their latest release has conda 22.9. It points to the conda-forge channel by default though, so you have to explicitly add Anaconda channels if you need them.

Also, just for your information, this CEP will not affect anything related to Miniconda releases. It purely deals with conda.

[mcg1969]

I think it depends on what is meant by "support".

As the long tail shows we still have quite old versions hitting our server. This is often because they are embedded in long-running systems, so updates are challenging. Or it might just be because this is the root environment they've been using for a long time and unnecessary updates always come with risk of breakage. Perhaps it is baked in an old VM or Docker container.

And from a user's perspective, why not stay where they are? If it's working for them, there is no need to fix it, unless we force them to: only when we add a new assumption to conda behavior that old versions do not meet; virtual meta packages for example. A simple security patch or even new convenience feature usually does not alter behavior in a breaking way, so if users choose to forego such an update they do not suffer significant consequences.

So I would like to make sure that we differentiate between these two kinds of "support" in any proposal we make. Conda is a piece of infrastructure and as such we should not expect everyone to adopt aggressive update strategies.

[brettcannon]

A simple security patch or even new convenience feature usually does not alter behavior in a breaking way, so if users choose to forego such an update they do not suffer significant consequences.

But it does impact those that are tool integrators of conda. If you take CPython as an example, even supporting just security fixes as a source release is enough to cause people to ask/demand that you support them and the version they are choosing to use because there is some semblance of upstream support.

we should not expect everyone to adopt aggressive update strategies.

What's aggressive to you?

[mcg1969]

Good feedback, Brett, thank you!

I often find myself dealing with people on that long tail. They have built out data science workflows that embed conda deeply enough that the version they are using is not top-of-mind. Above I mentioned the introduction of the virtual metapackages as once case that exposed a number of customers who were running exceedingly old versions of conda. This intersected, interestingly, with a surprising cohort of customers who were still running CentOS/RHEL 6!

The introduction of the compatible release operator ~= was another one. That one proved interesting because it was sort of a sleeper: it was introduced in conda in 2018, but it took awhile before its use began to appear in conda repodata. But when it did, it caused non-trivial pain for users who were running older versions of conda. For customers that needed time to update their workflows, we bought them time by showing them how to exclude the offending packages from their mirrors.

But I think it's important to point out that an important commonality in the examples I'm thinking of is that they aren't desktop cases. Instead these were cases where conda was embedded into systems and processes. When I think about how, for instance, VSCode leverages conda, I do think it is more reasonable to assume that users should be able to stay reasonably up-to-date.

In the end, what I'm thinking is that I would welcome a restrictive conda version support policy if we also explicitly endorse a commitment to a good-faith effort to minimize changes that break the basic behavior of conda in the manner that virtual metapackages and the compatible release operator did. We won't always be able to avoid that, mind you, but we're more likely to do it unintentionally if it's not consciously considered.

Note that I'm writing this as a stakeholder but not an official voter. In the end I will work with the consensus view!

[travishathaway]

Thanks for providing a different type of user perspective and historical context @mcg1969. I believe it will be possible to ensure stability in conda going forward via CEP-9: Conda Deprecation Schedule.

@kenodegard, brings a up a good point in saying that effectively we really only support the latest release of conda. We would like to support more, but we also need to make that this CEP does not set us up for failure. As @kenodegard, suggested it may be nice to introduce LTS releases that are tied to our "deprecation" releases, which means that we would only have to support three releases simultaneously.

After thinking about this some more and reflecting on the current capacity of the conda development team, I am still not convinced that we actually have the capacity to do this. In other words, if we agree to something like this, we may be setting ourselves up for failure, leaving our team vulnerable to getting bogged down in LTS version support. But, these concerns might be a little overblown. I am just trying to be conservative here.

Perhaps a way forward here would be to involve our community of users and developers more. Instead of putting the maintenance burden squarely on the current development team, we could instead announce that these LTS versions will no longer be patched by our team, but we will welcome community pull requests for bug fixes. The conda development team will subsequently handle any release related work.

I'm interested to know if any other OSS projects operate this way (i.e. we do not fix bugs with a release but will accept fixes for it). Surely there must be users out there willing to patch their own software and push it upstream, right? 🤷 😅

[brettcannon]

I'm interested to know if any other OSS projects operate this way (i.e. we do not fix bugs with a release but will accept fixes for it).

I can't remember where I have seen this, but I have seen it. Typically, though, it's been around unofficial support, e.g. patches from the community to keep an older version running unofficially as long as it didn't make code harder to maintain were accepted.

[rolweber]

It might be helpful if old conda versions could detect when breaking features have been rolled out to the repositories, so they can bail out with a meaningful error message. Of course that won't help with the old versions that are currently out there. But maybe add this to one of the next releases, which will become old versions in the future.

[kenodegard]

Not a fan of "development team", I suggest we use "maintainers" instead.

[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 proposal at your earliest convenience.

It needs 60 % of the Steering Council to vote yes to pass.

To vote, please leave yes, no or abstain as comments below.

If you have questions concerning the proposal, you may also leave a comment or code review.

This vote will end on 2023-04-06, End of Day, Anywhere on Earth (AoE).

[jezdez]

yes

[jaimergp]

It might be helpful if old conda versions could detect when breaking features have been rolled out to the repositories, so they can bail out with a meaningful error message. Of course that won't help with the old versions that are currently out there. But maybe add this to one of the next releases, which will become old versions in the future.

Anaconda.org could reject serving to old clients by detecting the version in the user agent, if available. Just leaving that thought out there before I forget :D

[jaimergp]

Yes.

[ocefpaf]

Yes.

[chenghlee]

Yes

[xhochy]

yes

[msarahan]

yes

[kkraus14]

yes

[goanpeca]

yes

[mariusvniekerk]

yes

[wolfv]

Yes

[jezdez]

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 14).

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

[jezdez]

Merging as this has passed.