SemVer policy?

[max-sixty]

Currently we have a loose notion of Semantic Versioning. We could firm that up a bit. Which of these requires a new version:

• The prql-compiler API — we don't really follow this at the moment — e.g. feat: error code #1993 technically breaks it, but i hadn't though we'd jump to 0.6 for that
• We do follow it for the language
• Should we follow it for bindings like prql-js? This receives lots of bindings relative to the rust library

Thoughts?

[aljazerzen]

At least in my eyes, prql-compiler, language and all the bindings have the same versioning scheme.

And we did discuss that even though sem-ver does not enforce it, we do not want to have breaking changes in patch releases (0.5.1 -> 0.5.2) and instead release a minor release (0.6).

So, I do think that we should use semver for bindings too, but just bundle all three points into one versioning scheme.

(And I don't think that #1993 is a breaking change - adding a field should not cause broken builds. Or am I wrong?)

[max-sixty]

And I don't think that #1993 is a breaking change - adding a field should not cause broken builds. Or am I wrong?

I would have thought that it did — constructing this Struct would break, matching on it without a .. would break, no?

[max-sixty]

but just bundle all three points into one versioning scheme.

I agree this would be good. If I'm correct about #1993, then we need to bump to 0.6.0 though, unless we adjust the definition a bit

I am totally fine with either! I don't think we should be that worried about having too many minor releases.

[eitsupi]

Considering the users who are using this downstream, I think it makes sense to inform them in a minor release that it contains breaking changes.
(Of course, the packages may always be unstable as it has not currently reached version 1.0.0.)

https://github.com/apache/arrow, for example, is a monolipo, with major releases about every two months for all packages in the repository.

Looking at the changelog at now, it doesn't seem to include any breaking changes, so 0.5.3 makes more sense for me.

[aljazerzen]

Then it is decided - the versioning scheme includes all three things together: language, compiler and all the bindings.

Next release can be discussed in #2010

[max-sixty]

Considering the users who are using this downstream, I think it makes sense to inform them in a minor release that it contains breaking changes.

Yes we could have a section in the Changelog "Breaking changes", or we could just indicate which are breaking in the text — I'm easy either way...