Issue #16729 has been updated by R.I. Pienaar.
I was affected by this - just like you'd be affected if you used EPEL or any other 3rd party repo. It's how the RHEL eco system works. I prepared for this by mirroring the packages I need and using that as a control point. This is well known and widely practised in the RHEL community as this affects every public repo equally. The question of weither or not 1 specific person was affected is really not productive or constructive, look at the policies in the RHEL world and do what everyone else does - that way there is no surprises to anyone. The only difference with EPEL and us is that EPEL will only do major version upgrades after its been widely reported as being a stable major release prior to that it lives in their -testing repo. But they *do* major versions upgrades and they *do not* rename packages or maintain a complex set of different package repo names. As we're now looking at an ever more complex matrix of released software - puppet, hiera, mcollective, razor, etc - we have to do the same and we can not seriously expect to use the different repo name for each of our products and then another set of repo names for each of their releases this will not help users. In mcollective I mitigate this problem by maintaining two active branches one for development and one for production, these go into different yum/apt repos and I only promote to the next major version once its stable. Note though stable does not equal not being backward compatible. Our move to semver in Puppet will help in the long run with this. ---------------------------------------- Bug #16729: When using the puppetlabs repositories, `yum install puppet` should be safe. https://projects.puppetlabs.com/issues/16729#change-72403 Author: Robert Rothenberg Status: Unreviewed Priority: High Assignee: Category: package Target version: Affected Puppet version: 3.0.0 Keywords: Branch: I work for a small company that is not yet ready to upgrade Puppet to v3. This upgrade may or may not cause problems for us (especially since we use a masterless network), but the upgrade will require us to devote time to test the upgrade. It would be much better if there were separate names for the distributions, say, puppet2. Users who want to delay upgrades can install puppet2 and use that until they are ready. # Updates JJM - I changed the title because different package names are a prescribed solution. There is at least one other alternative proposal, which is to use different repositories for incompatible releases. Whatever we decide on, yum install puppet should be safe for the end user. Releasing incompatible packages to the repository makes this unsafe for end users. # References * [Puppet Users - Puppet 2.7 v 3.0 in the PuppetLabs yum repo](https://groups.google.com/forum/?fromgroups=#!topic/puppet-users/Q14kTSE0pvY) * [Puppet 3.0.0 Release Announcement](https://groups.google.com/d/topic/puppet-announce/lqmTBX9XDtw/discussion) * [Puppet 3.0.0 breaking changes relative to Puppet 2.7.x](http://links.puppetlabs.com/telly_breaking_changes) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
