Recommendation for release naming

[norbusan]

Hi

Thanks for all your work! I have one suggestion: you named the release 2020.18102020 which is not good, because it will not sort or order in any reasonable way due to the date inversion. 2020.20201018 would be better - that is what we do in Debian, first the TeX Live release, followed by the YYYYMMDD timestamp of the last checkout.

Just a suggestion that I think might help you at some point in the future.

[naveen521kk]

Sure! I will apply it soon.

Currently the tests are failing with a weird error saying input line length is too long. I really don't know why it happens though. I will fix it soon and after that changing this would be easy enough.(Provided it shouldn't have problems wherein this release is smaller than original one).

[naveen521kk]

Now I see the seriousness of this issue. Why didn't I notice it?

Currently there is a version called 2020.28092020 which means whatever release I publish would be a waste. Now, even the version scheme you suggested would also not work. What I should do is publish a version greater than that. Ig this could become problematic if not fixed. One thing I can do is change the type of versioning it. Say maybe 2020.3.<date here> but that raise another question why there is that 3. Do you have better idea to go about this year @norbusan ?

[norbusan]

I don't think that 2020.3.NNNN will work, because most package managers compare by dot groups, so 2020 >=? 2020 followed by 3 >=? 28092020.

I suggest to just add 1 before the YYYY string so yse 2020.120201025 or so. That will sort definitely greater.

When TL 2021 is out, you can switch back to normal 2021.YYYYMMDD.

[naveen521kk]

I suggest to just add 1 before the YYYY string so yse 2020.120201025 or so. That will sort definitely greater.

The problem with adding a 1 is 2020.28092020 version is already published which means 2020.120201025 means it is still less than that. One thing I can do is to pack on 29 of each month with current version scheme and change it next year.(I am not gonna do it manually because I would definitely forget it so the python script is gonna help me.).

Also, https://docs.microsoft.com/en-us/nuget/concepts/package-versioning says about how version are done in chocolatey.

Also, this will compare the exact year and not when TL is released isn't it a problem?

[norbusan]

No, that is what I said, in the dot groups the comparison is numeric and 120201025 is numerically bigger than 28092020!

At least the package managers I know are doing numerical comparison between the single fields, not sure about chocolatey, though

[naveen521kk]

Oh! I never knew about these though. Definitely I will change it. It is just editing a small script if I am not wrong. Also, I will make sure this doesn't happen next year!

[norbusan]

Isn't there a way to check this? In Debian/Ubuntu we can use dpkg --compare-version versA REL versB and get a true/false return value.

[naveen521kk]

Isn't there a way to check this?

I don't know this. I will ask them on gitter or else I will make an issue on their repo to have that feature.

[naveen521kk]

I think they use Semanatic versioning at least that is what nuget uses, on which chocolatey was build. I will ask them.

[norbusan]

Semantic versioning is nothing different, it is only how you use your version numbers, not how they are compared.

Version comparison is hard coded in the package manager, semantic versioning defines when you bump major/minor version, but has no influence on how version numbers are compared.

[naveen521kk]

I asked them here. Let them reply.

[naveen521kk]

That feature isn't there sadly. I got reply on gitter and a new issue on their repo https://github.com/chocolatey/choco/issues/2145