youtube-dl versioning

[LucidOne]

So I'm trying to validate release versions for youtube-dl, but I'm a little lost how both 2020.06.16.1 and 2020.06.16 are valid versions. Does YYYY.0M.0D_MICRO match both or does it need some other notation?

[mahmoud]

Oh, seems like they have an optional MICRO segment for patches that happen on the same day, so it'd be YYYY.0M.0D.MICRO. Not sure about extra notation to represent optional segments. I think omitting latter segments isn't so unforgivable when it's still reasonably compliant with the intent of the core version (YYYY.0M.0D) in this case.

[mbarkhau]

We could assume that no sane person would put parentheses in their version numbers and introduce something like YYYY.0M.0D(.MICRO). Of course this syntax would have to be restricted to suffixes, or you would have to define precedence.

This is also common with python versions which use release tags that are omitted when it is final as opposed to alpha, beta, etc.

[LucidOne]

I'm not super picky on notation but one option might be something like YYYY.0M.0D<_MICRO>.
Either way I think calver could benefit from a more formal definition, as it will make automating release tracking easier.

[mbarkhau]

Off the top of my head, I can't think of a case where it would be an issue, but it should be noted that the <> characters are already used for version specifiers, e.g. pip install my-package<2020.8.29.

[mbarkhau]

@mahmoud can you clarify if you even want to specify something WRT. optional segments? Do you consider this within the scope of the calver.org project?

I also saw for example that WW is the week, but there are ISO calendar based weeks and US weeks (for strftime %W and %U respectively). Then I remembered we're talking about version numbers here, so it maybe doesn't matter and might be OK to not define it. Then again, if you have two different maintainers, it would be better if they use the same definition, IDK.

[mahmoud]

I've been thinking about it and I think it would be nice to specify optional components. CalVer is meant to be practical, I think youtube_dl is doing something very practical indeed. Full date version by default, resolving collisions (multiple releases on the same date) by adding an optional counter.

I'm liking the parentheses for exactly the reason you outlined, @mbarkhau. That said, I think this is a Python bias, as I've become aware that some versions use () and [] to specify version ranges (exclusive/inclusive, as in math).

Weeks is a separate topic, I'd open another issue for a discussion there. :)

[mbarkhau]

I found at least one example where () and [] are also used for version specifiers: https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8905

[LucidOne]

I'm not sure it is aesthetically optimal, but I'm wondering if < and > make sense because they are already considered reserved for version comparison and it wouldn't make sense to compare version format specifiers.

ie. YYYY.0M.0D<.MICRO> < YYYY.MM.DD doesn't make sense, so there shouldn't be a conflict.

[mbarkhau]

Since all characters appear to be used in some version specifier syntax, perhaps that shouldn't be the deciding factor.

I've instead had a look at existing notation for optional parts/segments. After a brief survey, I'm leaning toward [ ]:

• major.minor[.build[.revision]]: https://en.wikipedia.org/wiki/Software_versioning
• Major.Minor.Patch[-Suffix]: https://docs.microsoft.com/en-us/nuget/concepts/package-versioning
• [N!]N(.N)*[{a|b|rc}N][.postN][.devN]: https://www.python.org/dev/peps/pep-0440/#public-version-identifiers
• major[.minor[.release[.build]]][+]: https://developer.mozilla.org/en-US/docs/Mozilla/Toolkit_version_format
• major[.minor[.micro[.build]]]: https://wiki.c2.com/?VersionNumber
• [N!]N(.N)*[{a|b|rc}N][.postN][.devN]: https://www.python.org/dev/peps/pep-0440/#public-version-identifiers

I did not find examples for another notation.

[LucidOne]

I think there is some ambiguity regarding MICRO
I wonder if a 00MICRO notation is worth specifying.

[mbarkhau]

I don't think so. AFAICT these are synonyms: MICRO, PATCH and I don't think I have ever seen zero padding for them.