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 existingnormalize-version
and it could be overridden by user's system classes. - There would be no constraint that
normalize-component-version
returned a string; it could be an arbitrary object that would also be returned bycomponent-version
. - A new GF (
aesthetic-version
orversion-display-string
) would be added to provide a stringified form of the contents of theversion
slot. -
version-satisifes
is 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 component-version
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 version-display-string
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.