Re: [libvirt] Switch to a time based version number rule

On 06/13/2016 08:56 AM, Daniel P. Berrange wrote: For "some" major release changes have other implications. Perhaps ABI or RPC compatibility (or some other inter-operability concern). It'd be "hard" to add some feature in say February that would historically require the "need" for a major version bump and be forced to wait until the following January to get that feature in. Or conversely keep track that version M.1 or M.2 introduced some incompatibility. I have no hard examples, just trying to consider history of other projects I've been involved in. Then there's the migration issue - would we need come up with thoughts and policy around how to handle what can migrate to something else (or how many versions back we'd "restore" some saved object/domain). BTW: This version stuff becomes more complicated for downstream releases that can have longer cycles between minor releases. Consider RHEL ~6 month cycles - that means perhaps RHEL 7.4 and 7.6 could use drastically different libvirt version numbers (which hopefully wouldn't have some other incompatible change). Beyond that for certain enterprise corporations, using a "Major.0" is not allowed because "historically" in the industry a major.0 release comes with issues and has "compatibility implications". For one OS I worked on in the past, we specifically chose to make a release "7.1" instead of "7.0" for that very reason! We did create a 7.0 release, but it was *purely* an advanced development and limited release (highly controlled). For that release we had to be compatible with a 5.n release as well (there was also a couple of 6.n releases). Again the mindset being Major version number change implies major changes. Not against being avant garde with respect to our numbering (after all it's generally just a number). If we were to go this way, then I believe we should just start with the July release being "2.5.0". That way we don't have to "think harder" down the road. John