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