Re: Proposal: anaconda version number changes

[David Cantrell <dcantrell redhat com>]

David Cantrell wrote:
> I went to do a build today for rawhide and noticed that the version
> number in anaconda.spec on the master branch was behind the version on
> f10-branch.  All of the people I've told in bugzilla that their bug will
> be fixed in anaconda-11.4.1.59-1 will probably be a bit confused.
> 
> After fumbling around on IRC deciding what to increase it to, I thought
> I'd throw this message to the list for a discussion on changing the
> anaconda version numbering system.  The w.x.y.z method now is a bit hard
> to follow and doesn't necessarily line up with our releases now.
> 
> In IRC, there were some interesting suggestions.  I'll try to explain
> them here:
> 
> 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]
> 
> 2) [halfline] Use git-describe --tags to generate a minor version number
> that is the number of commits since the last tag.
> 
> 3) [me, others?] Go with an x.y version number, leave release as it is
> so that releng can toy with that as necessary.
> 
> 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 increased the rawhide version to 11.5.0.0 and we are now at 11.5.0.1
> (bogus .mo file caused me to rebuild).
> 
> 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.

Actually, if we were to adopt this proposal, we could align F-11 and
move anaconda to 11.6.0 for the x.y.z realignment and then start
incrementing the y value from there for the remainder of the F-11
development.  That would still keep our version numbers passing greater
than and less than tests in rpm.

-- 
David Cantrell <dcantrell redhat com>
Red Hat / Honolulu, HI