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@xxxxxxxxxx> Red Hat / Honolulu, HI _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
