SemVer

[amirebrahimi]

What is the expected enhancement?

We enjoy using rustworkx in our projects. Unfortunately, we end up with versioning issues because rustworkx doesn't seem to be on SemVer yet. Will there be a 1.0 version at some point and will SemVer be adhered to? It would allow us to specify more flexible versioning in our pyproject.toml files and help us not require minor releases.

[IvanIsCoding]

I will post more thoughts on this later but in general, we have refrained from breaking things as much as possible. The most memorable breaking changes from the Python code are:

• retworkx -> rustworkx renaming. And we still support the old name to this day!
• Migrating to custom-types e.g. returning rustworkx.PathMapping instead of a dictionary. This was because of performance

So overall I do hope that one day we will reach 1.0 in #1000 and so far we've been pretty ok at not breaking people. I think if you use rustworkx>=0.13.2<0.15 you shouldn't worry too much about the updates.

There are some blockers until then like #511, #663, and #1121. I will explain more later on what a good 1.0 is for us.

[amirebrahimi]

Thanks for the detailed explanation. For a little more context, we sometimes end up in dependency hell where we have multiple internal packages that use the same external dependency, such as rustworkx. Then, there are downstream, terminal projects that use two of our own packages, but those packages don't agree on a rustworkx version. For all our packages, we tend to use the ^ versioning approach where the version is the minimum required. For pre-v1 versions, this stops before the next minor version though. The downstream project we had that required two of our other packages didn't need the latest from one, so we just issued minor updates to older versions of both to bump rustworkx.

I'll share an article from the author of SemVer, which I didn't agree with at first, but have acclimated more towards. At our company we've moved towards having all of our projects use major versions for internal packages within a short period of time. Before v1, it was allowed to be a wild west with expectations since it wasn't nailed down in SemVer. We had started to invent a new policy for pre-v1 versions, which essentially made SemVer work the same, but at a minor version (e.g. v0.x.y.z where x changes were breaking). Poetry ^ versioning rules sort of work for that, but it's just more to keep in mind. So, in the end we went for what was simplest -- just use major version numbers. One criteria we have for making a v1 release is when other projects start to depend on it.

Either way, good with whatever you all choose, but figured I'd share the article.