On Dec 5, 2016, at 2:11 PM, Trevor Vaughan <tvaug...@onyxpoint.com> 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 - eric.soren...@puppet.com 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 puppet-dev+unsubscr...@googlegroups.com. 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.
