Probably they'll download that license and add it to their repository.
Over time we'll probably add one or more modules, and possibly revise the license text, and I'm wondering how that will affect URL versioning.
A proposal for how we handle persistent URIs (URLs)
When we add new modules or otherwise revise the text do we increment the minor version number in the generated URL like so: https://firstdonoharm.dev/version/3/2/full.txt (meaning HL version 3.2)
Also, when bumping the version number we should ensure that all previous canonical URLs remain functional.
The license builder under /build should always make use of the most recent version of the HL. Technically, we could let users choose to build from earlier versions of the license but I think that's a door of complexity we should not consider opening unless many users provide a good argument for doing so.
Suggestions on how to solve this issue:
Document how we intend to evolve URIs over time, what is subject to change vs. what should ideally never change. This documentation can be an entry under /learn, appended to the readme.md or live in a separate markdown file.
Idea: Should we include the version number in the generated HL badge?
Hi y’all,
I’ve been thinking about a possible corner-case which I’d like to get some feedback on.
Presently, if someone activates all modules they get these links:
Probably they'll download that license and add it to their repository.
Over time we'll probably add one or more modules, and possibly revise the license text, and I'm wondering how that will affect URL versioning.
A proposal for how we handle persistent URIs (URLs)
/build
should always make use of the most recent version of the HL. Technically, we could let users choose to build from earlier versions of the license but I think that's a door of complexity we should not consider opening unless many users provide a good argument for doing so.Suggestions on how to solve this issue:
/learn
, appended to the readme.md or live in a separate markdown file.Relevant reading