[ClusterLabs] Antw: Re: [ClusterLabs Developers] announcement: schedule for resource-agents release 3.9.8

[Kristoffer Grönlund]

Ulrich Windl <Ulrich.Windl at rz.uni-regensburg.de> writes:

>>>> Kristoffer Grönlund <kgronlund at suse.com> schrieb am 03.01.2017 um 11:55 in
> Nachricht <878tqsjtv4.fsf at suse.com>:
>> Oyvind Albrigtsen <oalbrigt at redhat.com> writes:
>> 
>>> Hi,
>>>
>>> This is a tentative schedule for resource-agents v3.9.8:
>>> 3.9.8-rc1: January 10.
>>> 3.9.8: January 31.
>>>
>>> I modified the corresponding milestones at
>>> https://github.com/ClusterLabs/resource-agents/milestones 
>>>
>>> If there's anything you think should be part of the release
>>> please open an issue, a pull request, or a bugzilla, as you see
>>> fit.
>>>
>> 
>> Hi Oyvind,
>> 
>> I think it's high time for a new release! My only suggestion would be to
>> call it 4.0.0, since there are much bigger changes from 3.9.7 than an
>> update to the patch release number would suggest.
>
> I don't know the semantics of everybody's release numbering, but for a
> three-level number a "compatibility"."feature"."bug-fix" pattern wouldn't be
> bad; that is only change the first number if there are incompatible changes
> (things may not work after ugrading from the previous level). Change the second
> number whenever there are new features (the users may want to read about), and
> change only the last number if just bugs were fixed (without affecting the
> interfaces).
> And: There's nothing wrong with "10" following "9" ;-)
>
> And if you are just happy to throw out new versions (whatever they bring),
> call it "2017-01" ;-)

There was a recent talk by Rich Hickey on this topic, his way of putting
it was that versions basically boil down to X.Y where Y means "don't
care, just upgrade" and X means "anything can have changed, be very
careful" :)

For resource-agents and the releases historically, I personally think
having a single number that just increments each release makes as much
sense as anything else, at least in my experience there is just a single
development track where bug fixes, new features and backwards
incompatible changes mix freely, even if we do try to keep the
incompatible changes as rare as possible.

But, keeping the x.y.z triplet is easier to maintain in relation to the
older releases. 

Cheers,
Kristoffer

>
> Regards,
> Ulrich
>
>> 
>> Cheers,
>> Kristoffer
>> 
>>> If there's anything that hasn't received due attention, please
>>> let us know.
>>>
>>> Finally, if you can help with resolving issues consider yourself
>>> invited to do so. There are currently 49 issues and 38 pull
>>> requests still open.
>>>
>>>
>>> Cheers,
>>> Oyvind Albrigtsen
>>>
>>> _______________________________________________
>>> Developers mailing list
>>> Developers at clusterlabs.org 
>>> http://lists.clusterlabs.org/mailman/listinfo/developers 
>>>
>> 
>> -- 
>> // Kristoffer Grönlund
>> // kgronlund at suse.com 
>> 
>> _______________________________________________
>> Users mailing list: Users at clusterlabs.org 
>> http://lists.clusterlabs.org/mailman/listinfo/users 
>> 
>> Project Home: http://www.clusterlabs.org 
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf 
>> Bugs: http://bugs.clusterlabs.org 
>
>
>
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://lists.clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org

-- 
// Kristoffer Grönlund
// kgronlund at suse.com