+1 The deprecation log is a great idea if we resign to the fact that Puppet Labs (um, Puppet...) is never going to stop breaking things in its addiction to change. Ansible & Salt - at least so far - are not inflicting this particular kind of pain on their users, and Puppet should charge ahead doing things the way it has always done at its own peril. (I get it that Ansible & Salt get to learn from the early mistakes of Puppet, and that's the burden of being the trail blazer, but people won't choose Puppet just because they're nice people.)
At a recent debate I attended in Sydney (Puppet vs Chef vs Ansible vs Salt) I noted that even one of Puppet's most loyal defenders was bemoaning the switch to Clojure, as if Puppet wasn't difficult enough already without switching to a functional programming language in parts of the code base. Of the large sites I'm aware of I'm not aware of any in my city where there are plans to upgrade to Puppet 4 yet. Sadly, I know of far too many where there are plans to migrate to Ansible or Salt, or even Chef (Chef's never been big in Sydney). Meanwhile Puppet's saying Puppet 3 is EOL this year. Well I think if Puppet 5 is planned for any time sooner than 5 or 6 years away from now, Puppet must have some kind of death wish. Not that anyone will listen to me, but are so many things that could be improved without planning breaking changes and feature deprecations. What can be improved? Well many of the supported Puppet modules. I recall seeing in a recent OpenStack report, the Firewall module cited as one of Puppet's leading edges. What wasn't mentioned is all the bugs in it. How about a major version bump on that one that fixes all the bugs and design issues? Gosh, I can only imagine if Puppet would turn its attention away from breaking things in Puppet 5, to filling in all the gaps in the Puppet Forge, Puppet's usability could improve dramatically. Beaker version 3 would be nice too. It needs to be significantly rewritten, documented far better than it is. On Monday, March 21, 2016 at 7:35:09 AM UTC+11, Thomas Gelf wrote: > > Hi Rob, > > nice proposal, would definitively help people to deal with the stated > problem. Another approach could be to break and deprecate less things. > > Sure, I'm just kidding ;-) I love moving things forward. But you know, > there's a grain of truth in every joke. We should not forget about the > fact that by the end of the day we are talking about a tool designed to > manage configuration. > > For many people right now the configuration manager is the fastest > moving target in their tool stack. Your proposal is telling me that we > have a cfgmgmt tool struggling with the amount of deprecations it > produces. Sad story. We work for the tool, not the other way round. > > Cheers, > Thomas > > Am 18.03.2016 um 19:12 schrieb Rob Nelson: > > Happy Friday, everyone! This morning I had some semi-intelligible > > thoughts about feature deprecation in Puppet, specifically because I got > > bit with an upgrade issue last night. We do user stories a lot at work, > > so I'm going to frame it that way. I was curious what other opinions > > people have on this problem and how it can best be addressed. Thanks! > > -- 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/2c58aaad-d76b-4bb1-b9d1-7457a119723b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
