anachronauts/jeff65

Versioning plan?

Opened this issue · 0 comments

Might be a bit premature, but better early than late. How do we plan to version this?

It's not a library, but it does provide an interface (in the form of gold-syntax), so SemVer might be an option. But to be frank, once we produce a stable release, I'd like to keep a strong commitment to backward-compatibility, i.e. any program which compiles correctly with no warnings on a previous version of the software should compile correctly on a later version (albeit possibly with warnings). In this case, we'd just be at 1.x.y forever, making the major version useless.

CalVer appeals. I'm inclined to suggest Twisted's scheme, i.e. YY.MM.MICRO. So if we were to cut a release at time of writing, it would be 18.8.0. (Actually, it'd be 18.8.0.dev0.)

In order to accomplish the backwards-compatibility thing, I'd suggest grabbing a page from Perl5's book, though with a variant. A breaking change to the language gets an identifier, and a directive can be placed at the top of the file to indicate which version of the language the file should be compiled with. Without a directive, Perl5 will just use an old version of the language. Personally, I'd prefer that this situation use the latest version, but issue a warning explaining this and suggesting adding an explicit directive at the top of the file.

Language versions could be as simple as use gold1, use gold2, etc., or be related to the version number, e.g. use 18.8.0. The latter has the disadvantage that not every compiler version will correspond to a language version. Maybe use some kind of semver-adjacent system for the language, e.g. use 1.0, use 1.2, and later, use 2.0.

Language directives should also select the appropriate stdlib version.