Release numbering and branches

[Nico Huber]

Hi folks,

now that we have a git repository [1] ready (thanks Stefan!), I've
visited again the flashrom development guidelines [2]. I stumbled
there over a very long, exemplary version number: "0.9.10.1". IMHO,
two things are wrong here: 1st there are too many dots for my taste,
and 2nd the former two numbers are meaningless.

To avert that, I call for naming the next release "1.0". If necessary
it would get point releases "1.0.1", "1.0.2" etc, of course.

Regarding the naming of release tags and branches, I really like what
the Linux people do. In their naming scheme the tag for "1.0" would
be named `v1.0` and the branch `flashrom-1.0.y`. With different pre-
fixes for tags/branches it's always obvious what is referred to, and
with a wildcard (here the `y`) in the branch name the ongoing develop-
ment is emphasized.

Opinions? other proposals?

Nico

[1] https://www.flashrom.org/git/flashrom.git/
[2] https://www.flashrom.org/Development_Guidelines

[Carl-Daniel Hailfinger]

Hi Nico,

On 10.08.2016 23:48, Nico Huber wrote:
> Hi folks,
>
> now that we have a git repository [1] ready (thanks Stefan!), I've
> visited again the flashrom development guidelines [2]. I stumbled
> there over a very long, exemplary version number: "0.9.10.1". IMHO,
> two things are wrong here: 1st there are too many dots for my taste,
> and 2nd the former two numbers are meaningless.
>
> To avert that, I call for naming the next release "1.0". If necessary
> it would get point releases "1.0.1", "1.0.2" etc, of course.

IIRC the criterion for 1.0 is/was having a new and well-working layout
engine. So if we get that merged, the next version will indeed be 1.0.
For releases after 1.0 it does make sense to go for 1.1, 1.2 etc. unless
we get some other major feature merged and make it 2.0.
> Regarding the naming of release tags and branches, I really like what
> the Linux people do. In their naming scheme the tag for "1.0" would
> be named `v1.0` and the branch `flashrom-1.0.y`. With different pre-
> fixes for tags/branches it's always obvious what is referred to, and
> with a wildcard (here the `y`) in the branch name the ongoing develop-
> ment is emphasized.

You do have a point. I have no strong preference as long as the scheme
is not too weird.
> Opinions? other proposals?
>
> Nico
>
> [1] https://www.flashrom.org/git/flashrom.git/
> [2] https://www.flashrom.org/Development_Guidelines

Regards,
Carl-Daniel

[Antonio Ospite]

On Wed, 10 Aug 2016 23:48:35 +0200
Nico Huber  wrote:
> Hi folks,

Hi,

I am just a user but (unfortunately?) I happen to have an opinion on
the matter, so here it is :)
> now that we have a git repository [1] ready (thanks Stefan!), I've
> visited again the flashrom development guidelines [2]. I stumbled
> there over a very long, exemplary version number: "0.9.10.1". IMHO,
> two things are wrong here: 1st there are too many dots for my taste,
> and 2nd the former two numbers are meaningless.

Personally I wouldn't mind having a 0.9.10, or even a 0.10.0 as long as
they mean something, I am elaborating more below. And if you are
worried about breaking lexicographic order, "sort -V" is a viable
workaround on GNU systems, and git can sort versions too:
  git tag -l --sort="version:refname"
> To avert that, I call for naming the next release "1.0". If necessary
> it would get point releases "1.0.1", "1.0.2" etc, of course.

A fixed scheme is more manageable: use always the same number of fields.
> Regarding the naming of release tags and branches, I really like what
> the Linux people do. In their naming scheme the tag for "1.0" would
> be named `v1.0` and the branch `flashrom-1.0.y`. With different pre-
> fixes for tags/branches it's always obvious what is referred to, and
> with a wildcard (here the `y`) in the branch name the ongoing develop-
> ment is emphasized.
>
> Opinions? other proposals?

One thing that came to mind is: if flashrom will ever become a shared
library + a program using the library, it could be worth using
something like the "Semantic Versioning" scheme http://semver.org/

According to that scheme changing the fields in an a.b.c version number
mean this:

a. MAJOR version when you make incompatible API changes,
 b. MINOR version when you add functionality in a backwards-compatible
    manner, and
 c. PATCH version when you make backwards-compatible bug fixes.

This way external users of the library can decide what version to
depend on, and packagers have a well-defined scheme for tracking
the soname.

Just my 2c.

As always thanks for flashrom, and congrats on the git repository.

Ciao ciao,
   Antonio