Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • A asdf
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 63
    • Issues 63
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 21
    • Merge requests 21
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • asdf
  • asdf
  • Issues
  • #50
Closed
Open
Issue created Dec 20, 2020 by Eric Timmons@etimmonsOwner

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:

  1. Add a new GF (normalize-component-version). The ASDF supplied method would fall back to the existing normalize-version and it could be overridden by user's system classes.
  2. There would be no constraint that normalize-component-version returned a string; it could be an arbitrary object that would also be returned by component-version.
  3. A new GF (aesthetic-version or version-display-string) would be added to provide a stringified form of the contents of the version slot.
  4. 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.

Assignee
Assign to
Time tracking