Re: Switch to a time based version number rule

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]