Exception section so that we can package things like black

[mariusvniekerk]

As a response to https://github.com/conda-forge/staged-recipes/pull/12485#discussion_r478619040 we probably want to adjust this policy so that things we already package adhere to it.

[ocefpaf]

We actually already "had that" as a verbal agreement. I never noticed that this was not in the document. Thanks @mariusvniekerk!

[mariusvniekerk]

Also, say you have a software that has

• only 1.*a* releases in the year 2020,
• 1.*.0 releases in 2021,
• only 2.*a* releases onward. And those 2.*a* releases are actually usable/decent.

presumably at that point the meaning of a differs. This is chiefly a concern for calver / zero-ver packages

[mariusvniekerk]

@mbargull can you rereview?

[scopatz]

Is there going to be a vote called for this?

[mariusvniekerk]

attn: @conda-forge/core

[mbargull]

Is there going to be a vote called for this?

Given that this does not change the mode of suggestion vs prescription, I don't think we need a vote. (But ppl. should still feel encouraged to review, nontheless!)

[scopatz]

I think we should get rid of these "shoulds" as they are causing too much confusion. I read both of these shoulds as a "must", ie with an implicit "if". "Once [IF] a non-prerelease version of such a package is available ..., [THEN] they lose this exception and should [MUST] publish future prereleases"

[mariusvniekerk]

i'd view that as out of scope of this particular clarification.

[mbargull]

i'd view that as out of scope of this particular clarification.

I very much agree.

... [MUST] ...

That change would definitely have to be voted on. Plus, you'd have to do some research and give reasons if such policy would be feasible with the existing diverse software release modes. I'm not saying I am against it, but I'd only support it given enough background information. If you, however, want to propose another wording that you find less confusion, but which still carries the "should" meaning, we can do that, of course -- I'm definitely supportive on clarifications!

[scopatz]

I guess it is fine as is, but I am in favor of not making the problem worse in this PR. I really do read what is written here as a requirement, so it is disconcerting to me that other there is another, looser interpretation.

[ericdill]

On the core dev call today the following was clarified:

• Need to vote to adjust this CFEP as per these changes
• @scopatz will submit a clarifying PR after this one is in.

[mariusvniekerk]

@conda-forge/core This PR falls under the Overall workflow and packaging policies policy, please vote and/or comment on this PR. This PR needs 50% of core to vote yea to pass. To vote please leave Approve (yea) or Request Changes (nay) reviews. If you would like changes to the current language please leave a comment or push to this branch. This vote will end on Wednesday September 9, 2020.

[mariusvniekerk]

Total headcount of core atm is 22 according to https://github.com/conda-forge/conda-forge.github.io/blob/d9a90ce895ab87b9c646b0b02b5322818787a51c/src/core.csv

Thus this vote passes with 12 Yays, and 0 Nays

[jakirkham]

Thanks Marius! 😄