Version naming · Coq Platform devs & users

One thing I forgot, is that I've already asked the snap store to provide track 8.13. If we name the platform 8.13.2021.02.x then it's OK, if we name it 2021.02.x then I've to for ask a change (not a big deal, it's mostly a note to self). [tracks are to let users stick to a major version and not have the package be updated automatically behind their back]

Théo Zimmermann (Feb 01 2021 at 15:41):

Keeping the major Coq version in the version of the platform makes sense for the same reason that you had to request a track in the Snap store.

Théo Zimmermann (Feb 01 2021 at 15:41):

So my preference goes to 8.13.YYYYMMDD.

Guillaume Melquiond (Feb 01 2021 at 15:45):

What is the point of writing a date then? Why not call it just 8.13.0?

Enrico Tassi (Feb 01 2021 at 16:23):

My problem is that 8.13.x would then be both a coq release and a platform release, and it could even be that platform 8.13.y does not include coq 8.13.y.

Enrico Tassi (Feb 01 2021 at 16:45):

Théo Zimmermann said:

Keeping the major Coq version in the version of the platform makes sense for the same reason that you had to request a track in the Snap store.

Some package have tracks named as a date, eg we could have 2021.02 and 2021.08 ... The only concern of the store managers is how often one of these pops up, and how long they live, and this would not change. (Having a "false start" is not ideal, but I can explain why we want to change and how, so I don't think it is a problem to amend the only existing track).

Théo Zimmermann (Feb 01 2021 at 17:19):

I'm not saying that you can't have a track in the Snap store with a date but that the reason why you want a track is precisely because the major version of Coq is so important that you don't want users to be upgraded without being aware. Same reason why you would keep it in the version name of the platform.

Théo Zimmermann (Feb 01 2021 at 17:20):

Also, if your track is 2021.02, then how do you call the minor update to this track that is released in March then?

Théo Zimmermann (Feb 01 2021 at 17:21):

Guillaume Melquiond said:

What is the point of writing a date then? Why not call it just 8.13.0?

As answered by Enrico, the main point is to make it separate from Coq's own release scheme.

Théo Zimmermann (Feb 01 2021 at 17:24):

OK I missed the parallel discussion going on in the CEP.

Théo Zimmermann (Feb 01 2021 at 17:25):

If you don't put the day, but an increasing number instead, then this resolves the question I was asking above.

Michael Soegtrop (Feb 02 2021 at 10:50):

Would it be correct to summarize the consensus so far as:

we want the first two numbers of the Coq version plus something increasing - either a short form date or a number
we don't want it to be confused with the Coq version number
we want it to be short and concise and easy to understand for users and package managers

How about using 8.13.X and simply clearly and visibly documenting that this does not mean it includes Coq 8.13.X? One way to emphasize this would be to make a few rather quick updates on 8.13 with increasing package set - say every 2 weeks, so that we are at 8.13.4 or so soon?

Another option would be to never use the same patch level for Coq and the Coq platform. Say we have Coq 8.13.0, then Coq Platform 8.13.1 and 8.13.2 and the next Coq version would be 8.13.3. It should be possible to coordinate this. Or back to my original 4 number proposal (Coq 3 number + extra).

Guillaume Melquiond (Feb 02 2021 at 11:02):

Michael Soegtrop said:

Would it be correct to summarize the consensus so far as:

we want the first two numbers of the Coq version plus something increasing - either a short form date or a number

I am not part of that consensus. I don't think the version of Coq is that meaningful when it comes to the Coq platform. (No one would ever think of basing the versioning of a Linux distribution on the version of the kernel. Same for Windows and macOS.)

Michael Soegtrop (Feb 02 2021 at 11:12):

No one would ever think of basing the versioning of a Linux distribution on the version of the kernel. Same for Windows and macOS

But then only rather few Linux applications depend on the kernel version. For Coq this is different.

Paolo Giarrusso (Feb 02 2021 at 11:50):

@Michael Soegtrop 8.13.date might work, but I’d strongly advise against 8.13.X

Paolo Giarrusso (Feb 02 2021 at 11:51):

If you have to document that 8.13.1 doesn’t mean 8.13.1, you have a problem, even for the people who read and understand those docs.

Paolo Giarrusso (Feb 02 2021 at 11:54):

Your “alternating versions” proposal is better, but I prefer your original idea, or anything where the two version numbers have a clearly different format.

Paolo Giarrusso (Feb 02 2021 at 11:57):

(sorry for repeating points by others)

Enrico Tassi (Feb 02 2021 at 12:19):

I'm for YYYY.MM.X for the platform and A.B.C for Coq (and I promise I won't change my mind again soon ;-)

Théo Zimmermann (Feb 02 2021 at 14:03):

we want the first two numbers of the Coq version plus something increasing - either a short form date or a number

Like Guillaume and Enrico, I'm not attached to having the Coq version part of the version of the platform. The version of Coq will not be the most important component to all users: some will attach more importance to the version of math-comp or to the version of CompCert.

Théo Zimmermann (Feb 02 2021 at 14:04):

But if we were to keep the Coq version part of the platform version, then I would favor the 8.13.YYYYMMDD solution.

Michael Soegtrop (Feb 02 2021 at 16:19):

I am fine with YYYY.MM.X, but I think we need to discuss when the YYYY.MM part changes. My opinion is that it should only change for major updates. We might initially tie it to the Coq version but do something else later. But I wouldn't like the idea of changing the YYYY.MM every time we do a release and use the .X only for several releases in one month. I personally find it hard to pick versions for software where the version is the release date.

Enrico Tassi (Feb 02 2021 at 17:05):

But I wouldn't like the idea of changing the YYYY.MM every time we do a release and use the .X only for several releases in one month.

I have a hard time understanding this last concern. Do you want to be able to distinguish in the platform version an update (of one or more package other than Coq) from an extension (adding more packages)?

Enrico Tassi (Feb 02 2021 at 17:06):

My opinion is that it should only change for major updates

I agree

Théo Zimmermann (Feb 02 2021 at 18:21):

I also agree with the idea of bumping YYYY.MM only a few times a year.

Théo Zimmermann (Feb 02 2021 at 18:23):

The standard platform release calendar should probably be to bump this part of the version number only every six month with new Coq releases, although it gives the liberty to bump it more often if there is a need for a new major update of the platform (e.g. to include a major update in one of the other packages or because a package is being removed).

Emilio Jesús Gallego Arias (Feb 02 2021 at 23:27):

Now that you mention it I was doing some quite similar for jscoq [see https://github.com/ejgallego/jscoq-builds/commit/0b524a36a7a306396a63fd19f32f565d1c72a52b ] in this case it was not date-based but commit based, but from that experience, and considering that at some point we may base the jscoq platform on the Coq platform I do think that in some cases you may bump the date quite a bit, for example mathcomp / vst / etc... may require a full platform update; when to bump the minor number: I'd say only for critical fixes

Michael Soegtrop (Feb 04 2021 at 16:30):

So is the following the final consensus:

Use the format YYYY.MM.PATCH or YYYY.MM+betaX
Change YYYY.MM only on major updates, including but not limited to Coq "2nd number" updates

Regarding when to update the PATCH part: besides critical fixes I think it makes sense to add new packages in between. Definitely the version of all existing packages should remain the same unless there is a critical fix and definitely everything must stay compatible with a patch release.

Michael Soegtrop (Feb 05 2021 at 08:46):

A last question on this: I wanted to make an update for 8.12.2.0. I guess I use the old naming scheme and name it 8.12.2.1?

Théo Zimmermann (Feb 05 2021 at 13:19):

Yes, that makes sense. Let's start the new naming scheme with 8.13 only.

Michael Soegtrop (Feb 05 2021 at 13:32):

OK.

Last updated: Jun 03 2023 at 05:01 UTC