update conda to 25.3.1#807
Conversation
|
@conda-forge-admin, please rerender |
|
@conda-forge/miniforge ready for review. |
| - conda =={{ version.split("-")[0] }} | ||
| - mamba =={{ mamba_version }} |
There was a problem hiding this comment.
Hey @millsks, can you remember why this change was needed? The main point of user_requested_specs is that it ends up in the History file, which is used by conda to see what the user wanted at install time. If we ==-pin here, then conda is less likely to offer updates. We chose >= intentionally when we set this up 🤔
There was a problem hiding this comment.
Hey @millsks, can you remember why this change was needed? The main point of
user_requested_specsis that it ends up in the History file, which is used by conda to see what the user wanted at install time. If we==-pin here, then conda is less likely to offer updates. We chose>=intentionally when we set this up 🤔
Hi @jaimergp . IIRC it was to make sure that whenever we installed Miniforge it had the same versions each time. We had approval for 25.3.1 for example, but not for the next subsequent versions.
The first few times we were ok, but as soon as the next versions of conda and the other packages came out it would use those newer versions and it technically wasn't the approved 25.3.1 installer anymore because of version drift.
If this needs to get reverted we can just modify it in our construct file again. We were trying to avoid too many changes to what the open source version was releasing.
For example when we build the installer we change out the conda-forge channel with our channels on our internal Artifactory and adding a few additional packages we needed internally, but we were keeping the versions of the packages that were originally there the same.
3 participants
Checklist
0(if the version changed)conda-smithy(Use the phrase@conda-forge-admin, please rerenderin a comment in this PR for automated rerendering)Fixes #806