Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de> writes: >>>> Kristoffer Grönlund <kgronl...@suse.com> schrieb am 03.01.2017 um 11:55 in > Nachricht <878tqsjtv4....@suse.com>: >> Oyvind Albrigtsen <oalbr...@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 >>> develop...@clusterlabs.org >>> http://lists.clusterlabs.org/mailman/listinfo/developers >>> >> >> -- >> // Kristoffer Grönlund >> // kgronl...@suse.com >> >> _______________________________________________ >> Users mailing list: Users@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@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 // kgronl...@suse.com _______________________________________________ Users mailing list: Users@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
