Eric, what IS the rough outline on how to avoid incompatible updates with a consolidated repo? I'm particularly interested in how it would work with puppetlabs/puppet_agent (since `latest` would suddenly have a much different meaning).
Rob Nelson [email protected] On Mon, Dec 5, 2016 at 4:25 PM, Eric Sorenson <[email protected]> wrote: > Hi all. tl;dr: We are proposing moving the open source package > repositories back to a single repository for Puppet-owned projects and > their dependencies. This represents a shift from our stated plan to release > major-version releases that might contain backwards incompatibilities into > their own Puppet Collection repositories, but as a result it will be less > confusing to use the packages and easier to stay current. > > Long version: When we released Puppet 3.0 in 2013, backward > incompatibilities between it and Puppet 2.7 broke a number of sites who had > configured their provisioning or package updates to install the latest > version of Puppet from our repositories. In order to prevent similar > breakage when we released Puppet 4 in April 2015, we introduced it into a > new repository called Puppet Collection 1 (PC1), so users had to opt in > rather than opt out. The idea was that future backward-incompatible updates > would trigger new Puppet Collections, which would also be opt-in, so that a > user could stay on PC1 and only move to PC2 when they were ready > (background reading: https://puppet.com/blog/welcome-to-puppet-collections > ). In practice, the switching costs to get everyone onto a new repository > seemed really high and for the most part the impact of releasing into the > existing collection was low, so instead we either shipped releases like > PuppetDB 4.0 into PC1 or deferred shipping versions with big changes, such > when we rolled back from Ruby 2.3 to 2.1 for puppet-agent-1.7.0. > > We've been exploring our options to balance between the following criteria: > > - avoid breaking sites, to not repeat the Puppet 2 to 3 pain > - provide a set of component packages that are known to work with each > other, and provide a basis for Puppet Enterprise platform releases > - encourage rapid adoption of new releases by the open source community > - provide commercial differentiation on support lifecycle, similar to the > RHEL / Fedora model > > We talked through a number of options in pretty exhaustive detail and have > tentatively settled on this as the best – or maybe "least bad" – course of > action: > > - make a release package with a new name (probably "puppet-release"), > eliminating the public face of "Collections" > - move the existing repository directory structure over to a top-level > "puppet" repo, leaving links in place for current PC1 users to avoid > breaking them. > - publish and promote the plan (probably including re-visiting that blog > post above and making a new one to advertise what's happening), including > instructions on how to avoid incompatible updates if you don't want them, > and updating https://docs.puppet.com/puppet/latest/reference/ > puppet_collections.html#puppet-collection-contents > - continue publishing any and all open-source releases to the "puppet" > repo, including major-version releases. > > The patching/update policy will remain as it is today, where only the > latest series receives patches. For instance, once Puppet 4.9.0 is out, > there will be no more 4.8.x releases. The package repositories which > contain Long Term Support Puppet Enterprise point releases will continue to > be private, but the branches/tags of the components that comprise these > point releases will remain public, so people could rebuild them if they > wanted to. > > Speaking of community upstream, we want to enable builds of Puppet that > behave reliably, stay current with our bugfixes and release cadence, and > run on OSes that Puppet Inc. doesn't commercially support. We've been > working to enable outside folks to rebuild and distribute our software and > are going to continue to focus energy on this. As a few examples, we are: > - working to get Puppet 4.x and Facter 3 built as standalone packages for > Solaris > - investigating the OS-native build toolchain for OSes with current > compilers like Ubuntu Yakkety and Fedora 25 (to avoid having to rebuild the > world to get the C++ packages built) > - making facter-3 installable via gem for testing and distro packaging > (FACT-1523) > - working on including the Docker-ized Puppet Server stack into CI so new > versions are automatically built and uploaded to docker hub along with > traditional packages. > > I'd love to hear your feedback (just reply on this thread) on the proposal > overall and additional steps that would make your lives easier (with > respect to packaging and repos, that is). Although the next major versions > won't be out for a few more months, we're looking to make the > infrastructure and policy changes before the end of the year, so please > chime in. > > --eric0 > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/puppet-dev/A53809BB-4B46-4EC1-86BD-3BAD1EC71C2E%40puppet.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAC76iT9mW6hWBwo3rb9kzQ3DvieEqLHXb8bRxE__CNPmu%2ByVnQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
