On 2013-06-26T21:31:14, Andrew Beekhof <and...@beekhof.net> wrote: > > Distributions can take care of them when they integrate them; basically > > they'll trickle through until the whole stack the distributions ship > > builds again. > If we let 2.0.x be anything like 1.1.x, I suspect this would be rather > difficult.
Not sure. With the sore exception of 1.1.8, the integration effort was reasonable, even for an Enterprise distribution. Yes, for changes so large and intrusive, a temporary branch (or a longer release cycle) would probably be preferable. > The change I'm thinking of (CPG codepaths and global variables) was becoming > a major support overhead and all-round headache. > I hadn't planned to make that change, but it was the best way to fix a bug > that was holding up the release. Yeah, that one. If it fixes a bug, it was probably unavoidable (though the specific commit (953bedf8f7f54f91a76672aeee5f44dc465741e9) didn't mention a bugzilla id). But that trickles through all consumers here - OCFS2, DLM, sbd. Means we have to do more validation than a -rc should normally need - normally, during an rcX phase, I'd expect small, well-contained bugfixes for regressions only. But perhaps this was one such exception. (Which bug did it fix, by the way? Can't immediately spot it from the commit code.) > Plus it is still my intention not to have API changes in 2.0.x, so better > before than after. I wonder how that will go ;-) I don't really mind the API changes much, for me it's mostly a question of timing and how big the pile is at every single release. If you consider the API from a customer point of view, the things like build or runtime dependencies on shared libraries aren't so much of an issue - hopefully, the distribution provider hides that before they release updates. Hence my "Oh well, I don't care" stance. What's more troublesome are changes to existing commands (even something minimal like "crm_resource -M" now generating a short location constraint, which could potentially break scripts that interact with the CIB), or major changes to log messages (since those do break customer's scripts and monitoring environments). > > Important is to of course keep the major/minor numbers of the libraries > > updated so one doesn't get runtime problems. > I have been quite diligent running ./bumplibs.sh in preparation for releases > for a while now. Yes. Didn't mean to say it isn't working, just wanted to mention it. Because an update that fails to install until all dependencies are fixed is (mostly) fine, but one that installs and then breaks really annoys customers ;-) Regards, Lars -- Architect Storage/HA SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org