So, short of swapping in the egrammar in as the default, I'm actually not seeing any change that is requiring the bump to puppet 4. It would be *nice* to remove deprecated functionality, and it would be really nice to get the egrammar, but we can also continue working on that as the feature flag, flesh it out some more, make it faster, even change the semantics of parts of the puppet language to something sane, all in the puppet 3.x series.
So...I'll open this up. Should we continue with Puppet 3.x? Is there a reason that we absolutely need to break compatibility to move forward? On Wed, Aug 28, 2013 at 12:22 PM, Rob Reynolds <[email protected]> wrote: > > > > 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. > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *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.
