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.