On Dec 5, 2016, at 2:11 PM, Trevor Vaughan <[email protected]> wrote:
> Hi Eric, > > Unfortunately, you've now built a distribution (a very minor distribution, > but one nonetheless). As such, I would *highly* recommend following the time > honored (and massively tedious) method of having something like collections > for rolling major release updates and snapshots in time as you roll forward. > > This is how we do it and we modeled it off of the CentOS, Ubuntu, Debian, > RedHat, Suse, etc... models where a lot of disparate moving parts need to > have some level of stability over time. But you control which agents are pointed at a given repo, right? That is kind of a fundamentally different design constraint: we want nearly everyone to start out from the same place and to carry as many people forward with new releases without them having to revisit their repository setup. > So, what I would find easiest to deal with would be something like keeping > the PC1, PC2, etc.... nomenclature but taking that whole hog. > > So: > > PC1 -> Latest everything in the PC1 distribution > PC1.0.0 -> Package snapshot at PC1.0.0 > PC1.0.1 -> Package snapshot at bugfix release PC1.0.1 > PC2 -> Latest everything in the PC2 distribution > PC2.0.0 -> Major breaking change from PC1.X > Do mean making each one of these things an entire separate repository? With its own release package, directory structure, and package contents for every operating system supported at that point? > PCX -> Insane stuff that might break, basically Fedora/Tumbleweed for Puppet I kicked around the idea of a smaller version of this for a while, but got stuck on the problem of how to get people using the latest-and-greatest *off* it if they wanted to stabilize onto a numbered release, and conversely what they'd do if a repo they were on was EOL'ed and no longer receiving security updates. > > Etc.... > > I would definitely not recommend making it difficult for users that need to > mirror repositories for offline networks. In terms of high compliance > environments, this is pretty much all of them. Is there something in the proposal that makes mirroring harder or easier than it is today? Eric Sorenson - [email protected] director of product, puppet ecosystem -- 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/0CB30596-CCDC-44A7-B71A-266F0EDC8178%40puppet.com. For more options, visit https://groups.google.com/d/optout.
