The dictatorship of versioning
Apologies to Didier for stealing the subject of his email chain from 2015, but it pretty accurately sums up my feelings on the subject as well!
I'm very interested in getting the changes over the finish line needed to allow more expressive version strings in ASDF systems. From what I can gather on that email thread and the discussion on launchpad, the approach proposed at the time was basically:
- Add a new GF (
normalize-component-version). The ASDF supplied method would fall back to the existing
normalize-versionand it could be overridden by user's system classes.
- There would be no constraint that
normalize-component-versionreturned a string; it could be an arbitrary object that would also be returned by
- A new GF (
version-display-string) would be added to provide a stringified form of the contents of the
version-satisifesis already a GF and doesn't need any changes.
I think such a protocol could still work, but I'm hesitant, as since then
component-version was explicitly documented to provide a string of dot
separated natural numbers or nil (by 156a8013). So having
return an arbitrary object may break user code that analyzes versions and
they'd be (rightfully) upset.
To deal with that, I'm wondering if we should add a GF named
component-raw-version that returns the contents of the
version slot. Then
component-version would either return the output of
if it meets the requirements or nil otherwise. Then in ASDF4,
component-version would go back to just returning the value of the slot and
component-raw-version would be removed.