Hi Jess, Good discussions,
From experience and would countenance against adding the full semver to the templateId, especially in the development phase. Inevitably there is a lot of to and froing between the app developer and the template developer, particularly if you are using form builders. It gets even more messy if you are uploading to a tool like CKM which works on the templateId as a key.
My current approach in development is…
- Just put the major version in the templateID name.
- Add the semver to the other_details metadata sem_ver =0.n.n asa stop-gap until ADL@ allows us to record that ‘correctly’.
I have started a conversation with @borut.fabjan of Better and @sebastian.garde of CKM about how we can get tooling to help us here.
Semver has worked very well for us at archetype level, since it is really helpful to understand the nature of a change major, minor etc and this will be equally helpful at template level.
One decision we took for archetypes was that for a V0 archetype, the minor and patch numbers really had no defined meaning i.e v0.2.3 the .2.3 could not be relied on as any number of breaking changes may have occurred.
This probably makes sense in the context of CKM but I certainly found it helpful, when doing rapid template iterations as part of covid-19 app development, to be able to flag a potential breaking change to the app developers by incrementing the minor number to signify a breaking change , and incrementing the patch number to signify a minor revision (albeit that the overall published state is still V0). Sebastian and I were discussing that earlier this week - semver itself seems not to care what you do with V0 numbering so we are not breaking any rules there.
Essentially for a .v0 we shift the numbering one to the right, and drop patch.
We definitely have to get smarter tooling here that interrogates the semver number but I’d keep the minor and patch numbers out of the templateID.
The other issue is whether versioning rules apply the same for templates and whether that just reflects a bubble-up of changes in the underlying artefacts. e.g a major version change in a child archetype -> major version.
There are complications where a minor change in a child archetype may be constrained out in the parent template, and as such is applying a real-world revision but after playing with a few scenarios we reckoned that it is safer to apply the rule consistently , and allow the tooling to flag that the change applies to an unused node, and let a human being decide if a minor version change should actually be applied, or just apatch. Currently that’s how CKM operates - makes a suggestion but allows human override.