7:56 a.m.
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 :|
8:15 a.m.
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
9:01 a.m.
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
11:55 a.m.
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 :|
12:46 a.m.
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 :|
10:12 a.m.
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
11:54 a.m.
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 :|
11:36 a.m.
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
11:42 a.m.
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 :|
11:57 a.m.
On Mon, 2016-06-13 at 17:42 +0100, Daniel P. Berrange wrote:
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
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
11:58 a.m.
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, 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
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 :|
12:09 p.m.
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
12:33 p.m.
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
12:38 p.m.
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 :|
12:34 p.m.
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 :|
3:17 a.m.
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
3:27 a.m.
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
3114
days inactive
3115
days old
16 comments
8 participants
participants (8)
-
Andrea Bolognani -
Cole Robinson -
Daniel P. Berrange -
Gerd Hoffmann -
Jiri Denemark -
John Ferlan -
Kashyap Chamarthy -
Martin Kletzander