[libvirt] Switch to a time based version number rule
Currently libvirt uses a 3 digit version number, except when it uses a 4 digit version number. We have the following rules - major - no one has any clue about when we should bump this - minor - bump this when some "significant"[*] features appear - micro - bump this on each new release - extra - bump this for stable branch releases [*] for a definition of "significant" that no one knows Now consider our actual requirements - A number that increments on each monthly release - A number that can be incremented for stable branch releases Ok, the micro + extra digits deal with our two actual requirements, so one may ask what is the point of the major + minor digits ? In 11 years of libvirt development we've only bumped the major digit once, and we didn't have any real reason why we chose to the bump the major digit, instead of continuing to bump the minor digit. It just felt like we ought to have a 1.0 release after 7+ years. Our decisions about when to bump the minor digit have not been that much less arbitray. We just look at what features are around and randomly decide if any feel "big enough" to justify a minor digit bump. Way back in the early days of libvirt, we had exactly this kind of mess when deciding /when/ to actually make releases. Sometimes we'd release after a month, sometimes after 3 months, completely arbitrarily based on whether the chances felt "big enough" to justify a release. Feature based release schedules are insanity and so we wised up and adopted the time base release schedule where we release monthly (except over xmas/new year period). I venture to suggest that the reasons for switching from feature to time based release schedules, also apply to version numbers. IOW we should switch to a time based version number change rule, instead of a feature based version number change rule. So what I'm suggesting is that we adopt the following rule - major: bumped for the first release of each year - minor: bumped for every major release - micro: bumped for stable branch releases Rather than wait until next January to adopt this rule, I'd suggest we pretend that it is January now, and thus switch our next version number to be 2.0.0, and jump to 3.0.0 in January 2017. IOW, over the next 2 years we'll do the following releases off master: - Jul 1, 2016 - 2.0.0 - Aug 1, 2016 - 2.1.0 - Sep 1, 2016 - 2.2.0 - Oct 1, 2016 - 2.3.0 - Nov 1, 2016 - 2.4.0 - Dec 1, 2016 - 2.5.0 - Jan 15, 2017 - 3.0.0 - Mar 1, 2017 - 3.1.0 - Apr 1, 2017 - 3.2.0 - May 1, 2017 - 3.3.0 - Jun 1, 2017 - 3.4.0 - Jul 1, 2017 - 3.5.0 - Aug 1, 2017 - 3.6.0 - Sep 1, 2017 - 3.7.0 - Oct 1, 2017 - 3.8.0 - Nov 1, 2017 - 3.9.0 - Dec 1, 2017 - 3.10.0 - Jan 15, 2018 - 4.0.0 - Mar 1, 2018 - 4.1.0 - Apr 1, 2018 - 4.2.0 - .... The stable release branch naming would just use the first major + minor digit in its name.. eg the stable branch for 2.3.0 would use v2.3-maint and do stable releases 2.3.1, 2.3.2, 2.3.3, etc. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Mon, Jun 13, 2016 at 13:56:54 +0100, Daniel P. Berrange wrote:
So what I'm suggesting is that we adopt the following rule
- major: bumped for the first release of each year - minor: bumped for every major release - micro: bumped for stable branch releases
Rather than wait until next January to adopt this rule, I'd suggest we pretend that it is January now, and thus switch our next version number to be 2.0.0, and jump to 3.0.0 in January 2017.
I like this idea. Predictable version numbers can't hurt anyone and they may sometimes even help. Jirka
On Mon, Jun 13, 2016 at 01:56:54PM +0100, Daniel P. Berrange wrote:
Currently libvirt uses a 3 digit version number, except when it uses a 4 digit version number. We have the following rules
- major - no one has any clue about when we should bump this - minor - bump this when some "significant"[*] features appear - micro - bump this on each new release - extra - bump this for stable branch releases
[*] for a definition of "significant" that no one knows
Now consider our actual requirements
- A number that increments on each monthly release - A number that can be incremented for stable branch releases
Ok, the micro + extra digits deal with our two actual requirements, so one may ask what is the point of the major + minor digits ?
In 11 years of libvirt development we've only bumped the major digit once, and we didn't have any real reason why we chose to the bump the major digit, instead of continuing to bump the minor digit. It just felt like we ought to have a 1.0 release after 7+ years. Our decisions about when to bump the minor digit have not been that much less arbitray. We just look at what features are around and randomly decide if any feel "big enough" to justify a minor digit bump.
Or if we had enough releases, then we bump it, pick one random feature and say it was because of that =) I, for one, like the idea. I would just start with 2.0.0 on the first release in 2017. But that's just to have the full year in each such release. Have a nice day, Martin
On Mon, Jun 13, 2016 at 04:01:56PM +0200, Martin Kletzander wrote:
On Mon, Jun 13, 2016 at 01:56:54PM +0100, Daniel P. Berrange wrote:
Currently libvirt uses a 3 digit version number, except when it uses a 4 digit version number. We have the following rules
- major - no one has any clue about when we should bump this - minor - bump this when some "significant"[*] features appear - micro - bump this on each new release - extra - bump this for stable branch releases
[*] for a definition of "significant" that no one knows
Now consider our actual requirements
- A number that increments on each monthly release - A number that can be incremented for stable branch releases
Ok, the micro + extra digits deal with our two actual requirements, so one may ask what is the point of the major + minor digits ?
In 11 years of libvirt development we've only bumped the major digit once, and we didn't have any real reason why we chose to the bump the major digit, instead of continuing to bump the minor digit. It just felt like we ought to have a 1.0 release after 7+ years. Our decisions about when to bump the minor digit have not been that much less arbitray. We just look at what features are around and randomly decide if any feel "big enough" to justify a minor digit bump.
Or if we had enough releases, then we bump it, pick one random feature and say it was because of that =)
I, for one, like the idea. I would just start with 2.0.0 on the first release in 2017. But that's just to have the full year in each such release.
Mostly I just want to start it now because chances are we'll forget about it by the time Jan 2017 comes around :-) Also since it'll be a slight change to stable release numbering (from 4 back down to 3 digits) it'd be nice to start doing that now, rather than in the middle of a holiday period where people are half asleep/drunk/not paying attention :-P Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Mon, Jun 13, 2016 at 05:55:57PM +0100, Daniel P. Berrange wrote:
On Mon, Jun 13, 2016 at 04:01:56PM +0200, Martin Kletzander wrote:
On Mon, Jun 13, 2016 at 01:56:54PM +0100, Daniel P. Berrange wrote:
Currently libvirt uses a 3 digit version number, except when it uses a 4 digit version number. We have the following rules
- major - no one has any clue about when we should bump this - minor - bump this when some "significant"[*] features appear - micro - bump this on each new release - extra - bump this for stable branch releases
[*] for a definition of "significant" that no one knows
Now consider our actual requirements
- A number that increments on each monthly release - A number that can be incremented for stable branch releases
Ok, the micro + extra digits deal with our two actual requirements, so one may ask what is the point of the major + minor digits ?
In 11 years of libvirt development we've only bumped the major digit once, and we didn't have any real reason why we chose to the bump the major digit, instead of continuing to bump the minor digit. It just felt like we ought to have a 1.0 release after 7+ years. Our decisions about when to bump the minor digit have not been that much less arbitray. We just look at what features are around and randomly decide if any feel "big enough" to justify a minor digit bump.
Or if we had enough releases, then we bump it, pick one random feature and say it was because of that =)
I, for one, like the idea. I would just start with 2.0.0 on the first release in 2017. But that's just to have the full year in each such release.
Mostly I just want to start it now because chances are we'll forget about it by the time Jan 2017 comes around :-) Also since it'll be a slight change to stable release numbering (from 4 back down to 3 digits) it'd be nice to start doing that now, rather than in the middle of a holiday period where people are half asleep/drunk/not paying attention :-P
Really good point, actually =) Agreed.
Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 06/13/2016 08:56 AM, Daniel P. Berrange wrote:
Currently libvirt uses a 3 digit version number, except when it uses a 4 digit version number. We have the following rules
- major - no one has any clue about when we should bump this - minor - bump this when some "significant"[*] features appear - micro - bump this on each new release - extra - bump this for stable branch releases
[*] for a definition of "significant" that no one knows
Now consider our actual requirements
- A number that increments on each monthly release - A number that can be incremented for stable branch releases
Ok, the micro + extra digits deal with our two actual requirements, so one may ask what is the point of the major + minor digits ?
In 11 years of libvirt development we've only bumped the major digit once, and we didn't have any real reason why we chose to the bump the major digit, instead of continuing to bump the minor digit. It just felt like we ought to have a 1.0 release after 7+ years. Our decisions about when to bump the minor digit have not been that much less arbitray. We just look at what features are around and randomly decide if any feel "big enough" to justify a minor digit bump.
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.
Way back in the early days of libvirt, we had exactly this kind of mess when deciding /when/ to actually make releases. Sometimes we'd release after a month, sometimes after 3 months, completely arbitrarily based on whether the chances felt "big enough" to justify a release.
Feature based release schedules are insanity and so we wised up and adopted the time base release schedule where we release monthly (except over xmas/new year period).
I venture to suggest that the reasons for switching from feature to time based release schedules, also apply to version numbers. IOW we should switch to a time based version number change rule, instead of a feature based version number change rule.
So what I'm suggesting is that we adopt the following rule
- major: bumped for the first release of each year - minor: bumped for every major release - micro: bumped for stable branch releases
Rather than wait until next January to adopt this rule, I'd suggest we pretend that it is January now, and thus switch our next version number to be 2.0.0, and jump to 3.0.0 in January 2017.
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
IOW, over the next 2 years we'll do the following releases off master:
- Jul 1, 2016 - 2.0.0 - Aug 1, 2016 - 2.1.0 - Sep 1, 2016 - 2.2.0 - Oct 1, 2016 - 2.3.0 - Nov 1, 2016 - 2.4.0 - Dec 1, 2016 - 2.5.0
- Jan 15, 2017 - 3.0.0 - Mar 1, 2017 - 3.1.0 - Apr 1, 2017 - 3.2.0 - May 1, 2017 - 3.3.0 - Jun 1, 2017 - 3.4.0 - Jul 1, 2017 - 3.5.0 - Aug 1, 2017 - 3.6.0 - Sep 1, 2017 - 3.7.0 - Oct 1, 2017 - 3.8.0 - Nov 1, 2017 - 3.9.0 - Dec 1, 2017 - 3.10.0
- Jan 15, 2018 - 4.0.0 - Mar 1, 2018 - 4.1.0 - Apr 1, 2018 - 4.2.0 - ....
The stable release branch naming would just use the first major + minor digit in its name.. eg the stable branch for 2.3.0 would use v2.3-maint and do stable releases 2.3.1, 2.3.2, 2.3.3, etc.
Regards, Daniel
On Mon, Jun 13, 2016 at 11:12:34AM -0400, John Ferlan wrote:
On 06/13/2016 08:56 AM, Daniel P. Berrange wrote:
Currently libvirt uses a 3 digit version number, except when it uses a 4 digit version number. We have the following rules
- major - no one has any clue about when we should bump this - minor - bump this when some "significant"[*] features appear - micro - bump this on each new release - extra - bump this for stable branch releases
[*] for a definition of "significant" that no one knows
Now consider our actual requirements
- A number that increments on each monthly release - A number that can be incremented for stable branch releases
Ok, the micro + extra digits deal with our two actual requirements, so one may ask what is the point of the major + minor digits ?
In 11 years of libvirt development we've only bumped the major digit once, and we didn't have any real reason why we chose to the bump the major digit, instead of continuing to bump the minor digit. It just felt like we ought to have a 1.0 release after 7+ years. Our decisions about when to bump the minor digit have not been that much less arbitray. We just look at what features are around and randomly decide if any feel "big enough" to justify a minor digit bump.
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.
Since libvirt has promised never to break API/ABI, that rule doesn't apply to use, which is one of the factors why we've never had any decision about when to bump the major version.
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).
WRT migration the only version number that is relevant at the QEMU machine type version numbers. The libvirt version number is never used for any functional logic decisions in our code. At most apps use the version number to decide when libvirt APIs appear, and that's not impacted by this suggested 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.
Yeah, these are all the kind of insane reasons marketing people come up with for changing version numbers on products. In reality users are not so dumb as to be fooled by this kind of thing, and as an independant project I don't think we need care about this kind of thing anyway :-)
Way back in the early days of libvirt, we had exactly this kind of mess when deciding /when/ to actually make releases. Sometimes we'd release after a month, sometimes after 3 months, completely arbitrarily based on whether the chances felt "big enough" to justify a release.
Feature based release schedules are insanity and so we wised up and adopted the time base release schedule where we release monthly (except over xmas/new year period).
I venture to suggest that the reasons for switching from feature to time based release schedules, also apply to version numbers. IOW we should switch to a time based version number change rule, instead of a feature based version number change rule.
So what I'm suggesting is that we adopt the following rule
- major: bumped for the first release of each year - minor: bumped for every major release - micro: bumped for stable branch releases
Rather than wait until next January to adopt this rule, I'd suggest we pretend that it is January now, and thus switch our next version number to be 2.0.0, and jump to 3.0.0 in January 2017.
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.
Yeah, we could do that. Although I illustrated it below, I didn't mean to imply that July would always be the N.5.0 release - that's just what happens if we do the long cycle for Jan/Feb. The slight variation would be to always use the month number as the minor version digit. I didn't want todo that though, since I think it would be confusing when we skip a digit due to not releasing in Feb. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Mon, 2016-06-13 at 13:56 +0100, Daniel P. Berrange wrote:
I venture to suggest that the reasons for switching from feature to time based release schedules, also apply to version numbers. IOW we should switch to a time based version number change rule, instead of a feature based version number change rule. So what I'm suggesting is that we adopt the following rule - major: bumped for the first release of each year - minor: bumped for every major release - micro: bumped for stable branch releases
I don't like this. A widely used convention is to bump major when breaking backwards compatibility, minor when adding features in a backwards-compatible way, and micro when fixing bugs that don't alter the interface. Releasing a 2.0.0 would read, for many, as we had just broken API / ABI compatibility. We should rather switch to bumping minor each release and keeping micro for stable branch releases. The only drawback I see is that the minor version would eventually become comically large, eg. we'll be at 1.60 in five years and we'll reach 1.100.0 by 2026. Not too big a deal IMHO. -- Andrea Bolognani Software Engineer - Virtualization Team
On Mon, Jun 13, 2016 at 06:36:50PM +0200, Andrea Bolognani wrote:
On Mon, 2016-06-13 at 13:56 +0100, Daniel P. Berrange wrote:
I venture to suggest that the reasons for switching from feature to time based release schedules, also apply to version numbers. IOW we should switch to a time based version number change rule, instead of a feature based version number change rule. So what I'm suggesting is that we adopt the following rule - major: bumped for the first release of each year - minor: bumped for every major release - micro: bumped for stable branch releases
I don't like this. A widely used convention is to bump major when breaking backwards compatibility, minor when adding features in a backwards-compatible way, and micro when fixing bugs that don't alter the interface. Releasing a 2.0.0 would read, for many, as we had just broken API / ABI compatibility.
That convention isn't applicable for libvirt since we promise to never break API / ABI, and we've already bumped major version number in the past without anyone getting confused. . The libvirt ELF so version number is explicitly separated and distinct from the release version numbers, as due to our ABI promise we are fixed at libvirt.so.0 forever. So I don't see any compelling reason to stick with major==1 forever in our release versions Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Mon, 2016-06-13 at 17:42 +0100, Daniel P. Berrange wrote:
On Mon, 2016-06-13 at 13:56 +0100, Daniel P. Berrange wrote:
I venture to suggest that the reasons for switching from feature to time based release schedules, also apply to version numbers. IOW we should switch to a time based version number change rule, instead of a feature based version number change rule. So what I'm suggesting is that we adopt the following rule - major: bumped for the first release of each year - minor: bumped for every major release - micro: bumped for stable branch releases I don't like this. A widely used convention is to bump major when breaking backwards compatibility, minor when adding features in a backwards-compatible way, and micro when fixing bugs that don't alter the interface. Releasing a 2.0.0 would read, for many, as we had just broken API / ABI compatibility. That convention isn't applicable for libvirt since we promise to never break API / ABI, and we've already bumped major version number in the past without anyone getting confused. . The libvirt ELF so version number is explicitly separated and distinct from
On Mon, Jun 13, 2016 at 06:36:50PM +0200, Andrea Bolognani wrote: the release version numbers, as due to our ABI promise we are fixed at libvirt.so.0 forever. So I don't see any compelling reason to stick with major==1 forever in our release versions
Fair enough. I still think people will be confused, but I guess once we start bumping the major version number once a year they'll get around to it. If we really want to go time-based, why don't we keep it really straightforward and predictable and do July 2016 -> 2016.7.0 August 2016 -> 2016.8.0 ... January 2017 -> 2017.1.0 February 2017 -> 2017.2.0 If we'll happen to skip a month for whatever reason, we can simply skip the corresponding minor number. I guess we could omit the leading "20" and still be safe for 80 more years. But not until libvirt's 100 years anniversary, so I'd advise against it ;) -- Andrea Bolognani Software Engineer - Virtualization Team
On Mon, Jun 13, 2016 at 06:57:01PM +0200, Andrea Bolognani wrote:
On Mon, 2016-06-13 at 17:42 +0100, Daniel P. Berrange wrote:
On Mon, 2016-06-13 at 13:56 +0100, Daniel P. Berrange wrote:
I venture to suggest that the reasons for switching from feature to time based release schedules, also apply to version numbers. IOW we should switch to a time based version number change rule, instead of a feature based version number change rule. So what I'm suggesting is that we adopt the following rule - major: bumped for the first release of each year - minor: bumped for every major release - micro: bumped for stable branch releases I don't like this. A widely used convention is to bump major when breaking backwards compatibility, minor when adding features in a backwards-compatible way, and micro when fixing bugs that don't alter the interface. Releasing a 2.0.0 would read, for many, as we had just broken API / ABI compatibility. That convention isn't applicable for libvirt since we promise to never break API / ABI, and we've already bumped major version number in the past without anyone getting confused. . The libvirt ELF so version number is explicitly separated and distinct from
On Mon, Jun 13, 2016 at 06:36:50PM +0200, Andrea Bolognani wrote: the release version numbers, as due to our ABI promise we are fixed at libvirt.so.0 forever. So I don't see any compelling reason to stick with major==1 forever in our release versions
Fair enough. I still think people will be confused, but I guess once we start bumping the major version number once a year they'll get around to it.
If we really want to go time-based, why don't we keep it really straightforward and predictable and do
July 2016 -> 2016.7.0 August 2016 -> 2016.8.0 ... January 2017 -> 2017.1.0 February 2017 -> 2017.2.0
If we'll happen to skip a month for whatever reason, we can simply skip the corresponding minor number.
Having a full year in there means more typing for everyone and I think skipping version numbers would actually be confusing, as it could people to think there was a missing release Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Mon, 2016-06-13 at 17:58 +0100, Daniel P. Berrange wrote:
If we really want to go time-based, why don't we keep it really straightforward and predictable and do July 2016 -> 2016.7.0 August 2016 -> 2016.8.0 ... January 2017 -> 2017.1.0 February 2017 -> 2017.2.0 If we'll happen to skip a month for whatever reason, we can simply skip the corresponding minor number. Having a full year in there means more typing for everyone
A bit, yeah. On the other hand, I think it would make it even clearer that the release schedule is entirely time-based.
and I think skipping version numbers would actually be confusing, as it could people to think there was a missing release
Think Ubuntu - they always have a six month gap between releases, but I've yet to hear anyone complain about that. -- Andrea Bolognani Software Engineer - Virtualization Team
On 06/13/2016 01:09 PM, Andrea Bolognani wrote:
On Mon, 2016-06-13 at 17:58 +0100, Daniel P. Berrange wrote:
If we really want to go time-based, why don't we keep it really straightforward and predictable and do
July 2016 -> 2016.7.0 August 2016 -> 2016.8.0 ... January 2017 -> 2017.1.0 February 2017 -> 2017.2.0
If we'll happen to skip a month for whatever reason, we can simply skip the corresponding minor number.
Having a full year in there means more typing for everyone
A bit, yeah. On the other hand, I think it would make it even clearer that the release schedule is entirely time-based.
and I think skipping version numbers would actually be confusing, as it could people to think there was a missing release
Think Ubuntu - they always have a six month gap between releases, but I've yet to hear anyone complain about that.
Honestly when I started reading Dan's initial mail I figured that's what he was going to propose and gets my ACK. It has the handy feature that at a glance even non-libvirt devs can tell exactly how old their libvirt version is, not counting stable distro backport frankenstein monster versions. And it should avoid any user confusion about whether bumping the major version means we are breaking API compat, or if it's based on some fancy new feature, etc. - Cole
On Mon, Jun 13, 2016 at 01:33:22PM -0400, Cole Robinson wrote:
On 06/13/2016 01:09 PM, Andrea Bolognani wrote:
On Mon, 2016-06-13 at 17:58 +0100, Daniel P. Berrange wrote:
If we really want to go time-based, why don't we keep it really straightforward and predictable and do
July 2016 -> 2016.7.0 August 2016 -> 2016.8.0 ... January 2017 -> 2017.1.0 February 2017 -> 2017.2.0
If we'll happen to skip a month for whatever reason, we can simply skip the corresponding minor number.
Having a full year in there means more typing for everyone
A bit, yeah. On the other hand, I think it would make it even clearer that the release schedule is entirely time-based.
and I think skipping version numbers would actually be confusing, as it could people to think there was a missing release
Think Ubuntu - they always have a six month gap between releases, but I've yet to hear anyone complain about that.
Honestly when I started reading Dan's initial mail I figured that's what he was going to propose and gets my ACK. It has the handy feature that at a glance even non-libvirt devs can tell exactly how old their libvirt version is, not counting stable distro backport frankenstein monster versions. And it should avoid any user confusion about whether bumping the major version means we are breaking API compat, or if it's based on some fancy new feature, etc.
As you say there though, age really isn't a good indicator of what is in a release precisely because of distro frankenstein backports, hence my desire to have a version number that avoids trying to encode semantic information. Any such encoding will always be misleading in some way or another. This just gets us back to basics where the version number is just a set of plain counters, where each digit is incremented at clear fixed points. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Mon, Jun 13, 2016 at 07:09:49PM +0200, Andrea Bolognani wrote:
On Mon, 2016-06-13 at 17:58 +0100, Daniel P. Berrange wrote:
If we really want to go time-based, why don't we keep it really straightforward and predictable and do July 2016 -> 2016.7.0 August 2016 -> 2016.8.0 ... January 2017 -> 2017.1.0 February 2017 -> 2017.2.0 If we'll happen to skip a month for whatever reason, we can simply skip the corresponding minor number. Having a full year in there means more typing for everyone
A bit, yeah. On the other hand, I think it would make it even clearer that the release schedule is entirely time-based.
But misleading wrt stable releases that don't line up with the months of the original releases.
and I think skipping version numbers would actually be confusing, as it could people to think there was a missing release
Think Ubuntu - they always have a six month gap between releases, but I've yet to hear anyone complain about that.
Well they don't go 1, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 which is what we'd basically end up doing. Anyway to get back on track, the key goal is getting away from the version numbers whose meaning is associated with any features changes in the release. In fact the goal is to go further and make sure that each individual version number is *completely* meaningless, except in how it relates to earlier version numbers. IOW, to avoid encoding any semantic information in the version number, whether it is about the feature changes, abi compatibility, or release date. The version number is purely an arbitrary counter whose digits increment on each release. Nothing more, nothing less. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Hi,
I venture to suggest that the reasons for switching from feature to time based release schedules, also apply to version numbers. IOW we should switch to a time based version number change rule, instead of a feature based version number change rule.
Makes sense.
- major: bumped for the first release of each year - minor: bumped for every major release - micro: bumped for stable branch releases
IOW, over the next 2 years we'll do the following releases off master:
- Jul 1, 2016 - 2.0.0
Why stick to arbitrary numbers? I'd move to 2016 or 16 for major for this year, and it make sense to use the release month as minor then for consistency, i.e. something like "2016.07" or "16.7.0" for the July 2016 release. I also like the systemd style which completely drops the pointless major/minor thing (except for stable releases) and simply counts up the release number. cheers, Gerd
On Mon, Jun 13, 2016 at 01:56:54PM +0100, Daniel P. Berrange wrote: [Snip some nice analysis about libvirt versioning history.]
I venture to suggest that the reasons for switching from feature to time based release schedules, also apply to version numbers. IOW we should switch to a time based version number change rule, instead of a feature based version number change rule.
So what I'm suggesting is that we adopt the following rule
- major: bumped for the first release of each year - minor: bumped for every major release - micro: bumped for stable branch releases
[...]
The stable release branch naming would just use the first major + minor digit in its name.. eg the stable branch for 2.3.0 would use v2.3-maint and do stable releases 2.3.1, 2.3.2, 2.3.3, etc.
FWIW, as a user of libvirt, this proposed change is nice, and will be more clearer. -- /kashyap
participants (8)
-
Andrea Bolognani -
Cole Robinson -
Daniel P. Berrange -
Gerd Hoffmann -
Jiri Denemark -
John Ferlan -
Kashyap Chamarthy -
Martin Kletzander