Stream: Coq Platform devs & users

Topic: Version naming


view this post on Zulip Michael Soegtrop (Feb 01 2021 at 10:48):

So we agreed on data based tag names?

view this post on Zulip Enrico Tassi (Feb 01 2021 at 10:52):

You mean "date"?

view this post on Zulip Enrico Tassi (Feb 01 2021 at 10:53):

I'm OK with it, I had no time to check on the CEP if others agree

view this post on Zulip Enrico Tassi (Feb 01 2021 at 10:56):

It seems nobody complained, I guess you are good to go.

You tested the DMG on an M1 (via rosetta)?

view this post on Zulip Michael Soegtrop (Feb 01 2021 at 11:48):

You mean "date"?

ehm, yes.

view this post on Zulip Michael Soegtrop (Feb 01 2021 at 11:49):

You tested the DMG on an M1 (via rosetta)?

Not yet - I wanted to try it with a clean OS but as it looks reinstalling the macOS on a M1 Mac Mini is a bit more complicated than expected.

view this post on Zulip Théo Zimmermann (Feb 01 2021 at 12:58):

I'm fine with this solution.

view this post on Zulip Théo Zimmermann (Feb 01 2021 at 12:59):

And I'm also fine with the intermediate solution mentioned by @Erik Martin-Dorel that would be 8.13.YYYYMMDD

view this post on Zulip Théo Zimmermann (Feb 01 2021 at 13:04):

I just added a comment in the CEP thread comparing the two.

view this post on Zulip Enrico Tassi (Feb 01 2021 at 13:45):

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]

view this post on Zulip 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.

view this post on Zulip Théo Zimmermann (Feb 01 2021 at 15:41):

So my preference goes to 8.13.YYYYMMDD.

view this post on Zulip 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?

view this post on Zulip 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.

view this post on Zulip 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).

view this post on Zulip 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.

view this post on Zulip 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?

view this post on Zulip 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.

view this post on Zulip Théo Zimmermann (Feb 01 2021 at 17:24):

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

view this post on Zulip 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.

view this post on Zulip Michael Soegtrop (Feb 02 2021 at 10:50):

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

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).

view this post on Zulip Guillaume Melquiond (Feb 02 2021 at 11:02):

Michael Soegtrop said:

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

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.)

view this post on Zulip 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.

view this post on Zulip Paolo Giarrusso (Feb 02 2021 at 11:50):

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

view this post on Zulip 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.

view this post on Zulip 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.

view this post on Zulip Paolo Giarrusso (Feb 02 2021 at 11:57):

(sorry for repeating points by others)

view this post on Zulip 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 ;-)

view this post on Zulip 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.

view this post on Zulip 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.

view this post on Zulip 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.

view this post on Zulip 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)?

view this post on Zulip Enrico Tassi (Feb 02 2021 at 17:06):

My opinion is that it should only change for major updates

I agree

view this post on Zulip 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.

view this post on Zulip 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).

view this post on Zulip 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

view this post on Zulip Michael Soegtrop (Feb 04 2021 at 16:30):

So is the following the final consensus:

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.

view this post on Zulip 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?

view this post on Zulip Théo Zimmermann (Feb 05 2021 at 13:19):

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

view this post on Zulip Michael Soegtrop (Feb 05 2021 at 13:32):

OK.


Last updated: Jan 30 2023 at 11:03 UTC