search

sarugaku / resolvelib

Resolve abstract dependencies into concrete ones
ISC License
138 stars 31 forks source link

Toward 1.0 #97

Closed webknjaz closed 1 year ago

webknjaz commented 2 years ago

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 https://github.com/sarugaku/resolvelib/issues/69#issuecomment-760968114 but it seems to have been missed. Plus it even confuses our contributors who attempt submitting not-very-well-thought bumps apparently: https://github.com/ansible/ansible/pull/76257.

pradyunsg commented 2 years ago

See https://github.com/sarugaku/resolvelib/issues/76#issuecomment-793723398

webknjaz commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 (https://github.com/sarugaku/resolvelib/pull/92#issuecomment-955139430). 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 commented 2 years ago

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 commented 2 years ago

https://github.com/ansible/ansible/pull/76257#discussion_r751240755 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 commented 2 years ago

Since https://github.com/sarugaku/resolvelib/pull/99#issuecomment-1001740207 now being postponed, shall we re-consider for a 1.0.x release?

notatallshaw commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

@uranusjr @notatallshaw @pradyunsg @webknjaz any idea?

uranusjr commented 2 years ago

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.