Releases

[sbarzowski]

The need for releases was mentioned in #206.

So far everyone was just using master (good) or vendored-old-master (not-so-good).

Versioning scheme situation is complicated, because we have two implementations. We need to indicate compatibility, but allow separate releases of bug fixes etc. I see two reasonable choices:

1. 0.x.y - where x is common between go-jsonnet and cpp-jsonnet. All changes to stdlib or the language will need to be reflected in x part. That would make x increment much faster than it currently does. The y part would freely change in go-jsonnet and cpp-jsonnet.
2. 0.x.y.z - where x.y is common between go-jsonnet and cpp-jsonnet. x would be for breaking changes, y for safe additions to the language/stdlib, z for implemenation changes.

I like (1) a bit more.

I would also add a suffix -go and -cpp to all versions, so that when we get a bug report we immediately know which implementation they are referring to.

[sparkprime]

You're proposing renaming C++ Jsonnet though, right? Otherwise we cannot reboot the versions. That means renaming in npm and pypi as well. Why don't we just cut releases at the same time for C++ and Go Jsonnet and give them the same version? The idea being that they are consistent in test behavior and stdlib completeness at that time.

[sbarzowski]

I'm not proposing any changes for existing jsonnet releases. Renaming existing versions would be quite crazy. I am proposing slight changes for the future versions.

The problem with having the same versions is that it is then hard to do little patch level releases, to quickly fix bugs, improve performance etc. It is natural to me to signify both the (common) language version and the version of implementation details. How could we handle the importer 30x slowdown bug with versions tied to C++-jsonnet?

With option (1) the first component of the version would be incremented faster (any language/stdlib change) and the second may diverge between C++ and Go (implementation version).
With option (2) we would add an additional "patch-level" component (implementation version) for new releases and otherwise it would be exactly the same as now (language version).

[sparkprime]

So you mean we start from 0.9.5 and just change the policy by which we increment each component from this point on?

With option (2) is it OK to add a 4th component at this stage, what does that mean for semver ordering?

[sbarzowski]

1. Yes (starting with 0.10.0)
2. It's not technically semver compliant, but afaik it's normal enough for pypi etc.

[marcelocantos]

One option that might be worth considering is to decouple language versioning from implementation versioning.

[sparkprime]

We could create a new repo called cpp-jsonnet, use google/jsonnet only for documentation, tests, exampes, and stdlib. Then versioning of that repo is the 'language version' and each implementation indicates its language version via submodule.

[ghostsquad]

Is the ultimate goal to deprecate the cpp version in favor of the go version?

[sbarzowski]

Eventually, yes - fully maintaining two versions is a pain. We are not rushing it, though.