>>> On 06.05.15 at 09:21, <wei.l...@citrix.com> wrote: > On Tue, May 05, 2015 at 04:54:01PM +0100, Jan Beulich wrote: >> All, >> >> on the hackathon we also discussed possibly changing the versioning >> of Xen. The main rationale for the proposal is that (just like in many >> other software projects) version numbers (in particular the major >> one) currently don't really convey much information. The proposal is >> to take gcc's new versioning scheme as a basis (i.e. I'm not going to >> claim that the below is an exact copy of theirs): Major releases >> always increment the major version number. Minor version 0 is >> reserved to the development cycle, i.e. the first release in any >> release series would be 5.1.0. RCs would be expressed through the >> 3rd digit, i.e. the first RC of the currently being worked on release >> would be 5.0.1 (there was some debate as to whether, despite >> being redundant, to attach -rc1 to it to make clear this is not an >> actual release). >> >> So comparing current and new schemes things would go >> >> OLD NEW >> 4.6-unstable 5.0-unstable (or 5.0.0) >> 4.6.0-rc1 5.0.1 (-rc1) >> ... ... >> 4.6.0-rcN 5.0.N (-rcN) >> 4.6.0 5.1.0 >> 4.6.1-rc1 5.1.1 (-rc1) >> ... ... >> 4.6.1 5.2.0 >> >> This additionally has the benefit that taking only the numeric >> part of the version string then would sort properly. >> >> Any comments or alternative proposals are welcome. > > One exceptional situation is that we had 4.1.6 and 4.1.6.1. I don't > expect that to happen very often, but we do make mistakes in the release > process and figure out we need to release a slightly updated version. > How does this fit into the proposed scheme?
I think we would just attach a .1 to the previous version the same way we did there, i.e. 5.2.0.1. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel