asciidoc @9.0.0rc2_0 breaks version checks

[fhgwright (Fred Wright)]

The version number format in the RC versions isn't as expected, and hence breaks at least one build procedure (ntpsec), and possibly others. If it's important to make an RC version available as a port, it should really be a -devel version, so that the normal port can adhere to the expected version format.

At the time of this writing, the latest release version is still 8.6.9. Even if the portfile were fixed to split off the -devel version, I'm not sure there's an easy way to make 8.6.9_X "newer" than 9.0.0rc2_0.

[fhgwright (Fred Wright)]

I've now discovered that the asciidoc version check in ntpsec upstream was reworked for unrelated reasons, so it no longer trips over this. The current ntpsec port is unable to build (even with -doc, due to the way the build script is written), but with a new release of ntpsec expected in a few days, the current version probably isn't worth patching.

That doesn't change the original point, which is that unexpected changes in version format are undesirable, but at least it's only a temporary issue for ntpsec. Whether other ports (or other non-MacPorts user projects) are affected, I don't know.

[ryandesign (Ryan Carsten Schmidt)]

Replying to fhgwright:

If it's important to make an RC version available as a port, it should really be a -devel version,

This is true generally but maintainers have the discretion to make exceptions to this rule if that seems to be the right thing to do—for example if a developer no longer releases stable versions or if the last stable version is very old and has problems that were fixed by newer development versions.

At the time of this writing, the latest release version is still 8.6.9.

According to the asciidoc web site that's true, but we had that version in MacPorts back in 2013 already. Clemens explained in [9875cffcfdb567e35e6a8d38608d46c73e6d3f91/macports-ports] that he updated it to 9.0.0rc1 in February 2020 because that supports python 3 whereas asciidoc 8 only supports python 2. We do want to move toward python 3 in MacPorts where possible since python 2 is no longer supported by its developers as of January 2020.

In fact the web site is wrong and a version 8.6.10 was released in September 2017 and is available at ​https://github.com/asciidoc/asciidoc/releases.

Even if the portfile were fixed to split off the -devel version, I'm not sure there's an easy way to make 8.6.9_X "newer" than 9.0.0rc2_0.

Increasing the epoch is the way to do that, if one wanted to do that.

[kencu (Ken)]

is there a reason to keep the (apparently) dead asciidoc when their website says everyone should move to asciidoctor and that is already in MacPorts?

[fhgwright (Fred Wright)]

Good point. I'll look into switching ntpsec on the next update. But there are 26 other ports using asciidoc.

[neverpanic (Clemens Lang)]

For interactive use and use in your scripts, you should definitely go with asciidoctor. We keep asciidoc because many build systems of other components still depend on it and its installed binaries and scripts.

As explained above, I've replaced asciidoc with the asciidoc-py3 fork since Python 2.7 is unsupported since 2020-01-01, so continuing to use it is not a suitable solution. If packages whose build systems use asciidoc now trip over the version number, they should be fixed to no longer do this (or not even check the asciidoc version at all).

Ideally, all dependent software would stop using asciidoc, but until such time arises, we'll have to fix the failures as they happen.