Recent Pull Requests to puppetlabs-stdlib has raised issues w.r.t how we
should handle stdlib going forward. We have also had a discussion about
types and providers in core and if they should be moved out to modules
in a "tier2". That discussion also raises issues about
backwards compatibility, and configuration of modules.
I am posting this to trigger a discussion and to collect requirements.
* Is there content in stdlib that really belongs in core?
* Is there content in stdlib that should never have been included (it
should really be in a different module)?
* How do we keep stdlib in sync with the Puppet version?
* How should module authors deal with their dependency on stdlib?
* How should we handle future, breaking changes?
* A function is corrected/modified and is thus not backwards
compatible (it is not deprecated, just changed behavior).
* A function changes signature (it is called with a different set
of arguments).
* Should we have "backwards compatibility" as a separate module for
those that want to use older modules on a newer Puppet? (e.g.
stdlib-puppet3compat).
* Do we have to namespace functions (to allow multiple versions of the
same function for different modules?)
* Do we have to use a scheme such as adding a number after a
function/type
* Do we need to implement module specific loading (allow multiple
versions of a function).
* What about types and providers? Since they all have to co-exist in
the same catalog it is not really possible to support multiple
versions. How should we deal with types and providers?
Ideas, concerns, requirements, questions ...
Regards
- henrik
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/lbp1rn%24gne%241%40ger.gmane.org.
For more options, visit https://groups.google.com/groups/opt_out.
