Version number changes when restructuring software

Question

We are open-sourcing a java software system that was previously proprietary. We loosely followed semantic versioning, by Tom Preston-Werner, where:

• Bugfixes imply a patch update (for example, 1.0.X)
• Changes to your Public API that are backwards-compatible imply a minor update (for example 1.X.0)
• Changes to your Public API that are backwards-incompatible imply a major update (for example X.0.0)

The task of open-source the system required us to rename packages. We also felt we should consolidate much of the modules that existed previously.

The restructuring tasks do not alter the Public APIs, but does change the dependencies for API users.

Where does restructuring/package renaming fit in to semantic versioning? How is a restructuring like this handled in well-know open source projects?

Answer 1

If client code has to be changed to work with a new version, that's an incompatible API change.