Re: Switch to a time based version number rule

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

 



  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


--
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]