[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Proposal: anaconda version number changes

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- 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 and we are now at
(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.

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]