On Wed, Aug 28, 2013 at 5:07 PM, Henrik Lindberg <
[email protected]> wrote:

> On 2013-28-08 21:33, Andy Parker wrote:
>
>> 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.
>>
>>  Fixing the semantics of undef is hard without breaking things.
>
>
Even if we put together a new interpreter to go along with the future
parser? It seems like that, turned on as part of --parser future, would
give us all the wiggle room needed to do it in the 3.x series


> One more release on 3.x with more deprecations could be nice anyway while
> also getting one more round of work on future parser out for beta testing.
>
> - henrik
>
>  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]
>> <mailto:[email protected]>> wrote:
>>
>>
>>
>>
>>     On Wed, Aug 28, 2013 at 10:45 AM, Andy Parker <[email protected]
>>     <mailto:[email protected]>> wrote:
>>
>>         On Wed, Aug 28, 2013 at 7:27 AM, Henrik Lindberg
>>         <henrik.lindberg@cloudsmith.**com<[email protected]>
>>         
>> <mailto:henrik.lindberg@**cloudsmith.com<[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<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 
>> puppet-dev+unsubscribe@**googlegroups.com<puppet-dev%[email protected]>
>>     
>> <mailto:puppet-dev%**[email protected]<puppet-dev%[email protected]>
>> **>.
>>
>>     To post to this group, send email to [email protected]
>>     <mailto:puppet-dev@**googlegroups.com <[email protected]>>.
>>
>>     Visit this group at 
>> http://groups.google.com/**group/puppet-dev<http://groups.google.com/group/puppet-dev>
>> .
>>     For more options, visit 
>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>> .
>>
>>
>>
>>
>> --
>> Andrew Parker
>> [email protected] <mailto:[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 
>> puppet-dev+unsubscribe@**googlegroups.com<puppet-dev%[email protected]>
>> .
>> To post to this group, send email to [email protected].
>> Visit this group at 
>> http://groups.google.com/**group/puppet-dev<http://groups.google.com/group/puppet-dev>
>> .
>> For more options, visit 
>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>> .
>>
>
>
> --
> 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+unsubscribe@**googlegroups.com<puppet-dev%[email protected]>
> .
> To post to this group, send email to [email protected].
> Visit this group at 
> http://groups.google.com/**group/puppet-dev<http://groups.google.com/group/puppet-dev>
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out<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.

Reply via email to