Dependency rules #205
Dependency rules #205
Conversation
There was a problem hiding this comment.
@felixfontein generally LGTM, a couple of minor things from me, thanks for doing this!
|
Hmm, looks like I lost commit access to this repository, so I cannot even update my own branch anymore :-( CC @gundalow @Andersson007 |
felixfontein
force-pushed
the
dependency-rules
branch
from
3499f34 to
38fe17c
Compare
| #. ``community.foonetwork`` depends on ``ansible.netcommon >= 2.0.0, <3.0.0``. | ||
|
|
||
| * ``ansible.netcommon 4.0.0`` is released during this major Ansible release cycle. | ||
| * ``community.foonetwork`` either releases a new version before feature freeze of the next major Ansible release that allows depending on all ``ansible.netcommon 4.x.y`` releases, or it will be removed from the next major Ansible release. |
There was a problem hiding this comment.
This should be determined automatically, and there should be some sort of a state-file holding this info between releases.
There was a problem hiding this comment.
This sounds pretty complicated for something that hopefully never happens, and if it does can be handled with issues and already preparing removal from the upcoming major version (as its ansible.in already exists in a new directory).
| * Collection dependencies must have a lower bound on the version which is at least 1.0.0. | ||
|
|
||
| * This means that all collection dependencies have to specify lower bounds on the versions, and these lower bounds should be stable releases, and not versions of the form 0.x.y. | ||
| * When creating new collections where collection dependencies are also under development, you need to watch out since Galaxy checks whether dependencies exist in the required versions: |
There was a problem hiding this comment.
Could you please expand what you mean by under development? Would that be <= 1.0.0?
There was a problem hiding this comment.
Yes. This is basically about two dependent collections simultaneously reaching the 1.0.0 goal while producing versions that satisfy our rules.
There was a problem hiding this comment.
Wouldn't it make sense to bar not only the collections under dev but also the ones that depend on collections under dev? I mean, if the purpose of the rule is reliability/stability, I suppose that would go a long way.
There was a problem hiding this comment.
We only accept collections that released version 1.0.0 for inclusion anyway. Also note that this part of this PR has been in the rules for years, it only moved to a new place in this document.
There was a problem hiding this comment.
I'm concerned with the use of the word "under development", what if that could be changed to "under developed"
Let's assume this - * When creating new collections where collection dependencies are also under developed,
What do you think?
There was a problem hiding this comment.
I'm not a native English speaker, but "under developed" seems to mean something completely different to me. ("in development" would be an alternative - https://english.stackexchange.com/questions/238497/which-expression-is-correct-in-development-or-under-development)
There was a problem hiding this comment.
Oooh, interesting I just learned that now. Thanks
Co-authored-by: Alexei Znamensky <[email protected]>
Co-authored-by: Tabah Baridule <[email protected]>
|
The new rules have been accepted (ansible-community/community-topics#94 (comment)) by SC vote. Any last comments before merging? |
Co-authored-by: Sandra McCann <[email protected]>
|
@Andersson007 @russoz @Dule-mart @jamescassell @samccann thanks a lot for reviewing this and suggesting improvements! |
|
Is all a pleasure doing this with everyone |
SUMMARY
This is what I described in ansible-community/community-topics#94
Let's polish this a bit, and if everyone seems happy let's vote on the result.
ISSUE TYPE
COMPONENT NAME
inclusion criteria