Metals: Release date-based versions

[olafurpg]

This is a proposal to start releasing date-based versions such as 2019.12.9 instead of semver v1.2.3 versions. Why?

• Metals is an application and not a library and I feel like date-based versions are a better fit for applications
• how do we define the cut-off for a v1 release? Currently, it looks like Metals will indefinitely stay in v0.x until every possible IDE feature is implemented (debugging, refactoring, ...). Once we reach that point, what will be the criteria for releasing v2? Staying on v0.x gives the impression that the project is still immature.
• we can configure our CI to release a "nightly" build with the same version the current date (2019.12.9 for today) and it'll be easier to users and maintainers to communicate about version numbers.

[laughedelic]

What about communicating stable releases vs. bugfixes to the users? If there will be nightly releases, they might be not as stable as those made once in a while that have been tested over time. I see the appeal of the date-based versioning, but I think that it still needs to communicate stability of the software somehow.

[gabro]

I agree that versioning by semver is a bit counter intuitive for an application, so I’m 👍 for an alternative versioning scheme.

I have the same concern as Alex about clearly marking the “stable” release, but I think it can be solved easily by prefixing the nightly release with “-nightly” or something like that.

If we go with nightly/stable, we could also choose to have an option on the vscode extension (and other clients) to follow the nightly as opposed to the latest stable release. I imagine the stable release will keep working as today (manual update needed on the clients to update the default) whereas the nightly version will just poll the latest version.

[tgodzik]

Totally agree with @gabro and @laughedelic , though in my very personal and biased opinion date based versions are a bit dry.

We could just got to 1.0.0 and then always up with stable releases:

1.0.0 - Cobalt STABLE
1.0.1
1.0.2
1.0.3
2.0.0 - Silver STABLE
2.0.1
...

We can use coursier to use latest release for nightly with "latest.release"

It's nothing that I feel very strongly about, just throwing it out there.

[gabro]

By the way, nobody forces us to use 3 numbers in the version.

We could easily do:

1.0 - Cobalt STABLE
1.1
1.2
1.3
2.0 - Silver STABLE
2.1
...

(just a thought, more than an actual proposal)

[olafurpg]

I'm fine with including a -nightly suffix for nightly builds. We could down the road introduce another -testing kind to get early feedback from users who want to test upcoming releases but don't want to stay on bleeding edge -nightly

[olafurpg]

Closing as won’t fix