Toward 1.0

[webknjaz]

Hi, could anyone post a public statement explaining if this project follows any specific versioning scheme? It'd be useful for the consumers to know how to set up the dependency boundaries.

I've asked this in a comment #69 (comment) but it seems to have been missed. Plus it even confuses our contributors who attempt submitting not-very-well-thought bumps apparently: ansible/ansible#76257.

[pradyunsg]

See #76 (comment)

[webknjaz]

Okay, so it's regular SemVer but below 1.0.0 SemVer doesn't apply so minor version bumps are breaking. Is that right? Maybe it'd be possible to document it in README?

[pradyunsg]

I'd prefer to bump to 1.0 instead of that -- if people start caring about API stability, I guess that's a good point to switch over to 1.0. :)

[uranusjr]

FWIW, semantic versioning says:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Although I bump the minor version for breaking changes instead, loosely following Cargo’s convention:

Initial development releases starting with "0.y.z" can treat changes in "y" as a major release, and "z" as a minor release. "0.0.z" releases are always major changes. This is because Cargo uses the convention that only changes in the left-most non-zero component are considered incompatible.

I think we’re pretty close to 1.0; the last thing I think need to happen is whether we need to change the interface to correctly introduce the Cause type (#92 (comment)). It doesn’t seem like it, but either way 1.0 should happen when that one’s finished. (Although I need to actually find time for that in the first place 😞)

[webknjaz]

Yep, I understand the SemVer and the below-1.0.0 implications. And I'm fine with capping the upper bound for minor releases. No rush to release 1.0 from my side. Just wanted to have something predictable and will pin accordingly. I can update the pinning convention post 1.0 release so it's not a big deal.

[hswong3i]

ansible/ansible#76257 (comment) show the challenge for downstream project supporting all resolvelib minor version API breaking changes before 1.0.0.

It case for capping the upper bound for minor release, usually we are assuming installation with virtualenv, which is not downstream deb/rpm packaging friendly.

Another workaround for pre-1.0.0 would be vendoring resolvelib locally as like as how pip now working, into Ansible. BTW, this workaround usually not acceptable by community, too.

IMHO bumping resolvelib toward 1.0.0 looks like the most elegant solution (in case Cause API breaking changes come later we could have 2.0.0, etc)

[hswong3i]

Since #99 (comment) now being postponed, shall we re-consider for a 1.0.x release?

[notatallshaw]

Since #99 (comment) now being postponed, shall we re-consider for a 1.0.x release?

I don't know if there is a particular timeline for implementing a causes object because if there is it almost certainly shouldn't be depending on me ;). I'm trying to fix a particular performance issue that my PR created and learn stuff along the way, anyone else is welcome to make a PR to implement this.

With regards to the PR itself, it seems to make mypy happy it would be easier to implement an AbstractCauses object in resolvelib that can be subclassed by the downstream, that way type hinting can be specific in resolvelib and not complain in pip? If resolvelib maintainers want to provide some guidance on if they think that's a good idea or whether the approach should be closer to #99 but better somehow I'd appreciate it. Otherwise when I get a chance I will try again and make another PR.

[uranusjr]

Is there progress on the Cause interface? If we still want to do that, it should go into 1.0. Otherwise I think we can release what we have now.

[notatallshaw]

No I have unfortunately not had time to work on this, further I have a new employer and I am still negotiating with them what open source work I can do.

Happy to work on this again soon but don't hold anything up for anything I'm doing.

[hswong3i]

Since #99 (comment) now being postponed, shall we re-consider for a 1.0.x release?

@uranusjr @notatallshaw @pradyunsg @webknjaz any idea?

[uranusjr]

I’m happy with what we have right now. So if things go as-is, I’ll cut 1.0 soon-ish (probably in May). Anyone should feel free to raise any objections though. I’m not particularly strong on reaching 1.0 (I think I mentioned this before, don’t remember where); the release is solely made because people ask for it.