Hive: Is there a reason for not following the Semantic Version convention for breaking changes?

[long1eu]

From the change log I can see that you introduced a few breaking changes without incrementing the major value of your version since 1.0.0.

Bellow is a list of all the versions and how they should be treated according to semver.

| current | semver |
|:-------:|:-------:|
| 1.1.0 | 2.0.0 |
| 1.1.0+1 | 2.0.0+1 |
| 1.1.0+2 | 2.0.0+2 |
| 1.1.1 | 3.0.0 |
| 1.2.0 | 4.0.0 |
| 1.3.0 | 5.0.0 |
| 1.4.0 | 5.1.0 |
| 1.4.0+1 | 5.1.0+1 |
| 1.4.1 | 5.1.1 |
| 1.4.1+1 | 5.1.1+1 |
| 1.4.2 | 5.1.2 |
| 1.4.3 | 5.1.3 |
| 1.4.4 | 5.1.4 |
| 1.4.4+1 | 5.1.4+1 |

Using this versioning system ensures that my code doesn't suddenly stop work and that I can safely put a constrain like this >=1.0.0 <2.0.0 being sure that everything will work as expected. Also this allows me to migrate the the newer version the I see fit.

https://semver.org/

[TheMisir]

If there's a standard, It doesn't means everyone should follow it.

Because "minor" and "major" are relative terms. For example take a look at Python. At the time of writing it's latest version is 3.8 (at least that's what I found on Google). Does it means python just had 3 or 4 breaking changes over the time? I'm sure there were tons of breaking changes that's considered "minor" for someones. So that's just my thoughts that semver isn't a rule it's just a convention whether you follow it or not. Also we tried to not break exists code as much as possible by providing alternatives to support previous versions or keeping @deprecated methods, classes etc.

[long1eu]

Thank you for your explanation. You are doing an amazing job.

[cachapa]

I'd like to reopen this discussion. I found this issue because I was concerned that the null safety changes are planned to have a bump the minor version rather than the major.

I understand your rationale regarding the relative meaning of semver, but Dart pub is opinionated and will upgrade minor versions automatically if they're specified with the caret style, as most people do: hive: ^1.4.4

Uploading a breaking change as a minor version bump will break builds for anyone using the above notation, which is why the Dart team recommends major version upgrades in those cases.

Reference: https://dart.dev/null-safety/migration-guide#package-version

[leisim]

@cachapa I agree

Edit: We should make breaking changes with new major versions. There's no disadvantage of creating major versions and it will avoid breaking projects that don't want to upgrade (yet).

[TheMisir]

But I think nullsafety versions will not break the exists users cause they are considered as prerelease and should be explicitly opted in to get those updates. Btw, I've already published 1.6.0-nullsafety.1 yesterday 👉👈

Because pub prefers stable releases when available, users of a prerelease package might need to change their dependency constraints. For example, if a user wants to test prereleases of version 2.1, then instead of ^2.0.0 or ^2.1.0 they might specify ^2.1.0-dev.1.

reference: https://dart.dev/tools/pub/publishing#publishing-prereleases

[leisim]

No if there are no API changes, null safety will not break existing code.

Btw, I've already published 1.6.0-nullsafety.1 yesterday

Amazing work :+1:

[cachapa]

But I think nullsafety versions will not break the exists users cause they are considered as prerelease and should be explicitly opted in to get those updates.

My understanding is that this is true only for as long as you keep the -nullsafety tag after the version number.
Once the new version of Dart is released and you remove the tag, all clients will pull the 1.6 dependency regardless of their local Dart version, and that will be a breaking change for those who haven't upgraded their SDK.

[leisim]

and that will be a breaking change for those who haven't upgraded their SDK.

Isn't nullsafety supposed to be backwards compatible in unsound mode?

[cachapa]

My understanding is that if you're in a very old SDK, your compiler won't understand all of those ? ! and late keywords and will fail to compile.

I suspect this wouldn't affect the vast majority of users since they're using Flutter which includes the latest Dart SDK, but it would affect anyone who hasn't touched their setup for a long while, and I would argue that those are exactly the type of users that shouldn't have their builds suddenly break.
My point is that build stability is important and we as package developers have the shared responsibility to do our parts in maintaining it.

To be fair, I also share a dislike for bumping the major version and wish Dart pub would stop upgrading automatically at minor, but at the end of the day it's just a number.

[marcelgarus]

Yes, because of the syntax changes, the migration to null safety is always considered breaking. According to Dart's Migration Guide, null-safe packages should be published under versions indicating breaking changes:

Update the version of the package to indicate a breaking change and include a nullsafety suffix:

• If your package is already at 1.0.0 or greater, increase the major version. For example, if the previous version is 2.3.2, the new version is 3.0.0-nullsafety.0.
• If your package hasn’t reached 1.0.0 yet, _either_ increase the minor version _or_ update the version to 1.0.0. For example, if the previous version is 0.3.2, the new version is one of the following:
  
  
  
  • 0.4.0-nullsafety.0
  
  
  • 1.0.0-nullsafety.0
  
  

For subsequent updates to the null-safe prerelease of the package, increment the prerelease suffix. For example, if the first null-safe version is 3.0.0-nullsafety.0, then the next one is 3.0.0-nullsafety.1.

You can maintain a stable release and null-safe prerelease at the same time. For example, if you have a stable release that’s 1.0.0 and a prerelease that’s 2.0.0-nullsafety.0, you can still publish new versions of the stable release (1.0.1) and null-safe prerelease (2.0.0-nullsafety.1).

Once null safety is available in a stable release of the Dart SDK, we encourage you to publish a stable version of your null-safe package.