> On 13 May 2019, at 12:35, Matthias Welwarsky <[email protected]> wrote:
>
> > what do you think about making periodic releases and possibly adopting
> > semantic versioning (semver)?
>
> Hm. That has a lot of implications.
>
> I cannot see openocd doing major/minor releases, let alone patches. There is
> no roadmap, no definition of what major/minor would mean. Given our
> contribution model, it doesn't seem viable. Contributions will hardly ever
> match up with features on a roadmap. We just have to take what's coming.
>
> Patch releases imply that a "stable" version exists to receive these patches.
> I don't see that happening.
I'm afraid there is a misunderstanding, I'm already using the semantic
versioning model for other projects and things are not at all that complicated.
btw, NPM, the node.js repository (https://www.npmjs.com) manages more than 8
Billions - with B - downloads **per week**, all governed by the semver rules
and everything works like a charm.
did you read the https://semver.org page?
when making semver releases, there are two really simple questions to ask
before deciding which number to increase.
1 - does the new version introduce any incompatibilities with the previous
version? like different behaviour, or removed functionality. if so, increase
the major version number and reset the minor and patch.
2 - does the new version add any new features or enhanced functionality
(without breaking compatibility)? like new commands, new scripts, new options,
etc. if so, keep the major number, increase the minor number and reset the
patch.
otherwise all changes are bug fixes; keep the major/minor and increase the
patch.
for those new to the subject, this is the essence of semantic versioning.
---
this approach does not need any roadmap, does not need to redefine the meaning
of major/minor, does not require any change in the contribution model, nor
anything special/unusual.
not even the repository needs mandatory changes, although a new branch to
easily identify the stable from the development content would be helpful.
there are at leat two possible ways for this new branch:
- a new branch like 'develop', and all new contributions switched to that
branch; when it is time for a release, the 'develop' branch is merged into
'master'
- a new branch like 'stable', and at release time the merges are from 'master'
to 'stable'.
in both cases, at release time someone with a good knowledge of the project
needs to answer the 2 questions above (by inspecting the commit history, for
example) and to decide the new version number.
2 planned releases per year, like in December and June, plus occasional patch
releases in case bugs are encountered and fixed, should probably be more than
enough.
in my opinion things are quite manageable. and the users have the immediate
benefit of knowing what to expect from a new release.
any other opinions favouring semantic versioning?
regards,
Liviu
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
