Re: Proposal: anaconda version number changes

[Chris Lumens <clumens redhat com>]

I'd like to start by saying I approve of using the Fedora release number
as the major version of anaconda.  While this does kind of create a
mental tie between a specific version of anaconda and a specific version
of a specific distribution, I think in this case it's okay.

> 1) [katzj] Use a major number for the version that matches the product
> release (so, 11 or 12 or Fedora, maybe x.y for RHEL--dunno) and use a
> git hash reference for the release number.  So we might have an nvr that
> would look like:  anaconda-12-[hashref]

How does NEVRA comparison work in this case?  Do we end up having
hashref as DDMMYYYgit<hash> to make that work?  In that case, eew gross.
That's entirely too much release version for me.  We might as well
rename it to java-anaconda at that point.

> 2) [halfline] Use git-describe --tags to generate a minor version number
> that is the number of commits since the last tag.

This is an interesting idea.  The biggest problem I see with this is
that we'd jump from 12.1 to 12.25 in a single build, and that seems
pretty weird to me.  I don't know that anyone really cares about the
number of commits between versions.  All we really care about is a
specific (and small) identifying number to tell people so they know when
to expect their fix.  So I don't see much benefit of doing this over
just having a regular minor version number.

> After thinking about it for a bit, I would like to see our version
> number change to the following system:
> 
> a) Use an x.y.z format (x=major, y=minor, z=patch)
> b) Tie the x value to the Fedora release number.
> c) Increment the y value for each build we make in Fedora.
> d) In Fedora, keep the z value at 0.  For products like RHEL, the z
> value will be incremented rather than the y value for development on
> that branch.
> e) Leave the release number at 1 or at least not have it contain
> anything of importance to the version number.  We should probably
> reserve this value for releng flexibility.

I think this is what I prefer.  For the average user, they'll only ever
see the X.Y version number.  RHEL users don't care about a slightly more
complicated version number because they're already used to
anaconda-i.j.k.l in 5.3-nightly-20081127.4-whatever-some-more-crud.

The release number is of little importance to me.  We only ever modify
it on release branches, which we almost never do.  I suppose we should
at least leave the option to do more stuff on those branches open by not
tying up the release number with some other meaning.

> Looking for comments on the proposal above.  The nice thing is now is
> this change isn't really critical as we were already at major version 11
> before even F-10, so we can't align the major version until F-12 anyway.

Yes, let's align this for F12.

- Chris