Latest upstream release: 2.7.1 Current version in Fedora Rawhide: 2.6.6 URL: http://downloads.puppetlabs.com/puppet/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring
I believe that 2.7.1 contains some backwards-incompatible changes. This would make deployment difficult in environments where users have a master running on an EL system. We keep puppet versions in sync across Fedora and EPEL for this reason and will likely not push 2.7.x to EPEL in the near term. In fact, 2.6 has been in fedora and epel testing for months now. Once it finally goes to the stable repos, we'll begin to evaluate 2.7 or 2.8 as needed. I'll also update my repos at tmz.fedorapeople.org at that time. (Upstream is also working to automate rpm builds, which will make for another source of the very latest, for folks that want to run the bleeding edge and don't mind having to make changes to their manifests and configurations as incompatible changes occur upstream.)
I also removed the entry in the upstream release monitoring wiki. If any other puppet maintainers would like it restored, feel free to do so (and I can plan to just ignore the "bugs" it generates ;).
*** Bug 723728 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > I believe that 2.7.1 contains some backwards-incompatible changes. This would > make deployment difficult in environments where users have a master running on > an EL system. We keep puppet versions in sync across Fedora and EPEL for this > reason and will likely not push 2.7.x to EPEL in the near term. > > In fact, 2.6 has been in fedora and epel testing for months now. Once it > finally goes to the stable repos, we'll begin to evaluate 2.7 or 2.8 as needed. > I'll also update my repos at tmz.fedorapeople.org at that time. (Upstream is > also working to automate rpm builds, which will make for another source of the > very latest, for folks that want to run the bleeding edge and don't mind having > to make changes to their manifests and configurations as incompatible changes > occur upstream.) IMHO, this is not right. Fedora is a bleeding edge distribution and should not be ruled by the needs of EPEL or EL. We should provide bleeding edge versions since that is our purpose, is it not?
(In reply to comment #4) > IMHO, this is not right. Fedora is a bleeding edge distribution and should not > be ruled by the needs of EPEL or EL. Compatibility is important. Many people use EL systems for their puppet masters. I care about those users enough to not have Fedora clients break that without a very good reason. > We should provide bleeding edge versions since that is our purpose, is it not? IMO, no. Fedora is not about bleeding. Certainly not at the expense of compatibility. Are you using the 2.6.x packages from testing? That's really not so ancient. I follow the puppet mailing lists and IRC channel a good bit, and typically, new major releases take a good bit of time to stabalize. We didn't introduce 2.6 to testing until 2.6.6, as prior versions suffered from various issues that would have caused unneccesary pain for users. This is also why I've provided packages on fedorapeople.org. It allows those who want to stay much closer to upstream do so in a way that helps improve the upstream codebase without affecting users that aren't interested in actively testing things. Puppet is still growing rapidly, but it is used by a wide variety of people now to manage a lot of systems. That makes it more imporant to balance stability and compatibility with the desire to run the latest and greatest.
(In reply to comment #5) > (In reply to comment #4) > > IMHO, this is not right. Fedora is a bleeding edge distribution and should not > > be ruled by the needs of EPEL or EL. > > Compatibility is important. Many people use EL systems for their puppet > masters. I care about those users enough to not have Fedora clients break that > without a very good reason. I don't agree on this point. I don't see backwards compatibility as an issue. GNOME3 is the proof that Fedora IS about bleeding edge and development. We attract collaboration and that's why the Userbase has it's place in the wiki: http://fedoraproject.org/wiki/User_base Let them (EL users) or, in this case, RH take care of these packages. Better yet, provide a legacy/compat package and the mainstream package. I'm sorry, I don't want to sound like I'm telling you what to do; I'm just trying to be clear. > > We should provide bleeding edge versions since that is our purpose, is it not? > > IMO, no. Fedora is not about bleeding. Certainly not at the expense of > compatibility. > > Are you using the 2.6.x packages from testing? That's really not so ancient. > I follow the puppet mailing lists and IRC channel a good bit, and typically, > new major releases take a good bit of time to stabalize. We didn't introduce > 2.6 to testing until 2.6.6, as prior versions suffered from various issues that > would have caused unneccesary pain for users. > > This is also why I've provided packages on fedorapeople.org. It allows those > who want to stay much closer to upstream do so in a way that helps improve the > upstream codebase without affecting users that aren't interested in actively > testing things. > > Puppet is still growing rapidly, but it is used by a wide variety of people > now to manage a lot of systems. That makes it more imporant to balance > stability and compatibility with the desire to run the latest and greatest. I am grateful about you taking the time to clarify this. I agree, 2.6 is not as far from the mainstream but, still, I do think we should provide bleeding edge (bind 9.5, even if it causes suffering, GNOME3, KDE 4.6 and stuff like that). Let CentOS-contrib handle it ;) That said; thank You for maintaining the package and the other repos. I will, indeed, stay close to upstream because of the great amount of changes and improvements they bring (ReST and one binary-for-all). I'm reading the book and I need to stay compatible to that. Be well.
Hi Renich, (In reply to comment #6) > I don't agree on this point. I don't see backwards compatibility as an issue. > GNOME3 is the proof that Fedora IS about bleeding edge and development. We > attract collaboration and that's why the Userbase has it's place in the wiki: > http://fedoraproject.org/wiki/User_base I'd say that puppet and its user-base doesn't fit into those categories terribly well. There are many types of users in Fedora, so we can't please everyone all the time. :) I believe, for the most part, that puppet users in Fedora quite often are running masters on EL systems and if we disregard compatibility it would cause more harm than good. At the least, we'd simply trade one bug report (i.e. Please update puppet) for another (i.e. Please _don't_ update puppet). > Let them (EL users) or, in this case, RH take care of these packages. Better > yet, provide a legacy/compat package and the mainstream package. Well, since puppet is not in RHEL, but in EPEL, it's maintained by volunteers. Even so, the compatibility issues would be present. A compat package would be a lot of work to maintain and isn't something I would be able to do well. > I'm sorry, I don't want to sound like I'm telling you what to do; I'm just > trying to be clear. It's alright. The feedback is appreciated, as is your pleasant tone. Thank you for that. > I am grateful about you taking the time to clarify this. I agree, 2.6 is not as > far from the mainstream but, still, I do think we should provide bleeding edge > (bind 9.5, even if it causes suffering, GNOME3, KDE 4.6 and stuff like that). > Let CentOS-contrib handle it ;) > > That said; thank You for maintaining the package and the other repos. I will, > indeed, stay close to upstream because of the great amount of changes and > improvements they bring (ReST and one binary-for-all). I'm reading the book and > I need to stay compatible to that. I hope to update to 2.7.x once we get 2.6.x into the stable repos, though upstream is also working on setting up some repos to help users keep up to date. Michael Stahnke, an active EPEL contributor and Puppet Labs employee is leading that effort. http://groups.google.com/group/puppet-users/msg/aca1f77639b5c8d5 > Be well. And you as well.