On 17 Nov 2021, at 15:12, Eric Timmons wrote:
On 11/17/21 2:38 PM, Robert Goldman wrote:
On 17 Nov 2021, at 13:31, Robert Dodier wrote:
On Wed, Nov 17, 2021 at 10:45 AM Robert Goldman
rpgold...@sift.info
<mailto:rpgold...@sift.info <mailto:rpgold...@sift.info>>
wrote:
I favor something like this because it would be nice to have
prerelease versions of ASDF that perform version checks
properly.
What I mean is, if we are going to add a feature in version
3.4,
right now that would be in a prerelease version with a
version
number of something like 3.3.5.22
It would be a lot better for realistic testing if we could
instead use 3.4.0-alpha1 or 3.4.0-1 and have ASDF know that
3.4.0-1 comes before 3.4.0, not after.
Hi Robert, hi everyone. I haven't been following closely, but
while
you are working out details, let me just mention that I
recommend
against version numbers that require special interpretation
to
discover their ordering, e.g. 3.4.0-1 < 3.4.0.
Mostly I'm just thinking that somebody's not going to get the
memo
(it's usually me).
For what it's worth, and all the best.
I guess that would be an argument for using something more
obvious than |-|, like the string |alpha| so |3.4.0-alpha1|
or
|3.4.0alpha1| instead of |3.4.0-1| since there the meaning
should be relatively obvious.
My feeling is that if a user misinterprets |3.4.0-1|, then
shame
on me. But if a user misinterprets |3.4.0alpha1| then shame
on them.
I'm not sure how that would align with semver...
Erik already sent out some examples of ordering with semver. But
it
is worth noting that 3.4.0-1 *is* valid semver and the ordering
would be 3.4.0-1 < 3.4.0-alpha
So to prevent misinterpretation of 3.4.0-1, ASDF could either
promise to always use something like alpha/beta/etc, use
something
else like PEP440 (I believe that grammar always requires an
alphabetic character for pre-releases), or bake its own grammar.
One thing that's nice about the semver grammar is its
flexibility. I
have some scripts that can generate a version string from a git
repo
that lets you easily order versions based on things like when
they
branched off the default branch. But if we want ASDF to disallow
things like 3.4.0-1, I'm happy to build my own system that uses
the
new API to allow the use of semver strings.
Another option is to choose something compatible with Debian's
version strings. I'm having a little trouble grokking it at the
moment, but it seems to be even more freeform than semver and
adds
an optional epoch prefix.
What might be nice would be to support a /subset/ of semver by
default -- not allowing the numerical prerelease flagged with |-| --
but do so in a way that is extensible.
Here's my rationale: I would like to provide a relatively simple
semantic versioning that is also compatible with automatically
detecting and rejecting ill-formed version strings.
So, for example, we could (by default!) split the version strings by
|#\.| and |#\-| and /reject/ any string bounded by |#\.| that is not
numerical.
We could demand, again by default, that the substring following the
|#\-| be of some constrained form: e.g., Greek letter name followed
by optional numeral. For that matter, we could just say "hey, alpha
and beta are enough" and reject anything but those two. That would be
a nice alternative to having a big table of Greek letter names in
ASDF!
Finally, for those who want to really go for it, we could add a
|:version-scheme| keyword to |defsystem|, which would initially
default to |:unconstrained|, but then through the standard process of
warning and then erroring, migrate to |:standard| (or perhaps
|:asdf|) as the default, but let anyone who wants to make up their
own versioning scheme. |semver| would be an obvious extension.
Hm. That's a bit more complex than I had hoped, but it would mean
ASDF systems would initially continue to work, it provides for some
error checking, and a path to extension.
