Release what's currently planned as 2.1 as 3.0 to comply with semver

[TadeasKriz]

I just switched from 2.0.x to develop and my code broke because of breaking changes (for example Region renamed to DateRegion). I would like to use this ticket as a reminder that it should be released as 3.0 and not 2.1. If this is already planned, just close this issue and carry on. Thanks!

[Hout]

Hmmm, v2 introduces DateInRegion but was still a bit quirky indeed. v2.1 is the bug fix but introduces no major changes. Check the develop branch.

A major release should have incompatible API changes link but from a functional perspective. Currently I am working to make v2.1 backward compatible with v2.0.

Thanks for your idea!

[TadeasKriz]

Not DateInRegion but DateRegion which was Region in 2.0. And since Region and DateRegion are both public and thus part of the API, renaming the class (and removing functions, renaming input parameters) is breaking the API and is not backward compatible.

[Hout]

Aaaah! Correct, I will include a typealias for backward compatibility and deprecate later.

[Hout]

Fixed in 416f751

[TadeasKriz]

@Hout I think that there were some more changes, for example the initializer's parameters of the DateRegion are different than Region. Also I think the versioning does not mean what version of the module, but the platform (so in the commit you say it is available since any platform's version 2.1). Also there are removed functions (like the UTCRegion() mentioned in my other ticket) which also break the API compatibility. Easiest would be to make this release 3.0 as there are many changes in the public api.

[Hout]

I am convinced.
@malcommac what is your opinion?

[malcommac]

Yeah seems reasonable; we will label it as 3rd version :)

[Hout]

Agreed. Closed