I do see at semver, which Julia follows, including the package manager (and thus all packages?):
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
And I also saw a discussion on Discource today on a package perceived to be abandoned, in version 0.1, when in fact it was complete, and no additions planned.
When people have these incorrect assumptions that not yet 1.0 means immature, it doesn’t help the Julia community. And I’m thinking, will many packages never hit 1.0, as they don’t need breaking changes? This is possibly more common for Julia, with many (small) packages, easily usable together, while other languages may have more monolithic frameworks.
These aren’t issues specific to Julia, unless Julia [package manager] demands semver. Python’s version system doesn’t assume semver (some packages may use), and is strictly incompatible, or at least a (non-strict) superset of it.
Maybe I’m wrong and you’re allowed to jump to 1.0 without any breaking changes. Not sure there’s a downside to doing it. Then I think package owners should consider it. I realize many have a long list of TODOs (sometimes just in their heads) or wish to dos, that may never get there… So when would you upgrade?
You are definitely allowed to increment the major version without making breaking changes. (For example, I don’t think there were any breaking changes between Julia 0.7 and 1.0). The thing that is disallowed is breaking changes without increment.
A common reason to stay at 0.x even though there are no planned changes is that there might be feedback from users that causes that plan to change.
I do like that Julia focuses on semver and that these discussions happen in the community. As a “contract” between the package developer and the user, I like to know that if a package is 0.X, I have to be careful to use any functionality in critical code. At the same time, I also know that I can isolate an environment with exactly that version of the package and this should always work.
Also, it’s reasonable to expect API changes in a package version 0.1, and if the developer consider the package to be “complete”, he/she should do a 1.0 release.
Clear rules create clear expectations a,d I believe those are good in an diverse open software community.
SemVer is a semantic recommendation that programmers can choose to follow (it is recommended). The package manager
Pkg does not analyze code, so it cannot enforce SemVer. It is for humans.
I don’t think this is a big issue. Also, as others pointed out, you are allowed to increment major versions without breaking changes.
Please do invest some effort into investigating things before initiating discussions like this. The idea of enforcing breaking changes for major version bumps is quite outlandish and it is unclear where you got it from.