On Wed, Aug 28, 2013 at 10:45 AM, Andy Parker <[email protected]> wrote:
> On Wed, Aug 28, 2013 at 7:27 AM, Henrik Lindberg < > [email protected]> wrote: > >> [snipped] >> > > I would have a slightly different list: > > * Split the codebase (master/agent/common? > apps/types+providers/language? something else?). We need to decide where > the right lines are to make the split and then figure out the work that it > will take to get there. This may or may not change how puppet is deployed, > but I think we can do it in a manner where we deploy in the same manner as > right now. > * Promote the egrammar to the default grammar. Do we keep the old > grammar around for ease of migration for users (I think we shouldn't)? > * Optimize the egrammar. It has to be faster than the existing grammar, > otherwise I don't think we can promote it. > * #8040 - anchor pattern. I think a solution is in sight, but it didn't > make 3.3.0 and it is looking like it might be backwards incompatible. > * Puppet Doc - I agree, this has sat and rotted for too long. It doesn't > show up on any of our roadmaps :( It seems to have just been forgotten > about. > * Remove all of the currently deprecated functionality (activerecord > store configs, many other things) > * Reboot support - This is being worked on, but didn't make it in time > for Puppet 3.3 (part of it did, but not all of it) > Reboot support only needed small bits into puppet core. What we would look at for 4 would be integrating the core type into puppet proper and just having the provider in the puppetlabs-reboot module. Another thing we would add to puppet is having the ability to report on why resources get skipped ( http://projects.puppetlabs.com/issues/15963) > > Something that we also need to work out is how much Puppet 4 can break > compatibility. I've been aiming for the conservative approach were we try > to only break compatibility, when possible, by first providing a > deprecation warning for the old behavior, have the new behavior available > at the same time and then remove the old behavior in a major release. This > approach would mean that we can't change language semantics for the Puppet > 4 release because we haven't deprecated a lot of the behavior and provided > a new set of behaviors. I'm willing to be told that we can take a larger > step than that, though. > > [snipped] > -- Rob Reynolds Developer, Puppet Labs Join us at PuppetConf 2014, September 23-24 in San Francisco -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
