Improve description of versioning in archetype Identification.

Description

See for explanation.

Activity

Show:

Ian McNicoll January 25, 2021 at 4:07 PM

That makes sense but the real value we (me and others like Vanessa from Better) is that actual version tracking is helpful when working iteratively with technical colleagues e.g on and end-user UI or form-builder when we usually inadertantly) make a breaking or even significant minor change, usually 10 minutes before an important demo.

It also makes it much easier to understand the potential impact of importing e.g. a recently updated archetype into a local repo - right now we get a ‘something’s changed’ warning,based on MD5 - but really hard to know the potential impact without a lot of work. So much easier if you can see - ah yes just a patch change - carry on.

I can also see all sorts of tooling improvements that could follow - on - better diffing… force zero constraints on any new optional elements/internal terms introduced in a minor change, and it opens up a whole proper NPM/Maven/NuGet package management approach as per the Dips approach.

Thomas Beale January 25, 2021 at 3:01 PM

Marand is now Better.

On the Q of initial version numbers, I don’t have a strong opinion on it, but the old logic used to be that you started on a sub-zero number that roughly indicated the maturity of the draft. A close-to-releasable draft of something (usually imported from something else that already works) would be 0.8.0, and ‘my rough idea on this’ draft would be 0.0.5 or so. Personally I still think this approach is more useful, but if we just want to start everything on 0.1.0, fine as well I guess.

Ian McNicoll January 25, 2021 at 2:25 PM

Yes - apologies

0.1.0 would make sense for unpublished and would fit with my proposal for improved unpublished version tracking.

Sebastian Garde January 25, 2021 at 2:04 PM

SemVer suggests now (it didn’t always) that the “simplest” way is to start with 0.1.0.

I probably agree and it makes some sense - but “simplest” doesn’t mean in my understanding that 0.0.1 is necessarily wrong.

1.1.0 as first published version is not correct, this is still 1.0.0, Ian? This should be clear from the FAQ https://semver.org/#how-do-i-know-when-to-release-100

Ian McNicoll January 25, 2021 at 1:44 PM

I’m happy to accept but Fabio recently alerted Sebastian Garde and I that the current semver spec says the ‘intial version’ should be 0.1.0 (unpublished) or 1.1.0 (published).

currently we say …
First version rule: the first version (i.e. version on creation) of an artefact is a v0 version, i.e. 0.N.P. Usually it is 0.0.1, but may be a higher v0 version to indicate maturity. The discussion of lifecycle and distributed semantics below provide more details on the initial version semantics. “

I suspect this was based on an early version of Semver where this had not been specified. Might it make sense to squeeze this change in here?

Done

Details

Reporter

Raised By

Thomas Beale

Original estimate

Components

Affects versions

Created May 21, 2018 at 2:59 PM
Updated March 8, 2021 at 11:51 AM
Resolved March 8, 2021 at 11:51 AM