On Fri, Sep 28, 2012 at 4:15 PM, Aaron Grewell <[email protected]> wrote: > On Fri, Sep 28, 2012 at 2:49 PM, Michael Stahnke <[email protected]> > wrote: >> Puppet 3.0.0 is a feature release for the 3.x series of Puppet. > >> * Semantic Versioning - With 3.0.0, Puppet Labs makes a commitment to >> follow the Semantic Versioning guidelines outlined on semver.org. >> Public, documented APIs won't break until 4.0; minor-version 3.x >> releases will add new features while retaining compatibility, and >> tiny-version 3.0.x releases will be bugfix-only. >> >> ## DSL/Config Changes >> >> * As part of a Google Summer of Code project, we have a completely >> rewritten Ruby DSL. Some of it is backwards-compatible, but other >> things have changed pretty dramatically > > Out of curiosity, how will the above be reconciled? Adding the new > Ruby DSL after 3.0.0 seems like it would violate a strict > interpretation of SemVer. >
You are absolutely right :( The way I'm reconciling this is that the existing ruby dsl is very experimental and very broken and should not be considered final. My philosophy is that when a piece of software reaches a "stable" version number, not every new piece of functionality that goes in will be as stable as that version number suggests. These immature features need to be called out so that they aren't given the same weight as the rest of the system. The Ruby DSL is one of those aspects. Unfortunately it has not been well communicated that it wasn't really fully working, nor was it documented (a few blog posts don't count). What this means is that some things that are undocumented may change, but they were never documented in the first place, so there was no guarantee given. Once we have things explicitly documented, then we'll do everything we can to hold ourselves to those documented behaviors. Whenever we do end up having to change these undocumented behaviors, I'm going to push really hard to make sure whatever the new behavior is becomes documented and supported. If it turns out that we need to make changes to documented parts of the system, then things get complicated. A bug fix would be that we are bringing the implemented behavior in line with the documented behavior. If we find a case where we have to change the documented behavior, then it is time to start putting together a new API that sits along side the existing one. The existing API would become deprecated and users would be prompted to move to the new API (there may be a lag between finalizing the new one and deprecating the old one as we iron out wrinkles and get feedback on the new one). On the whole what I want to see if a 3.x line of puppet that tries to keep our documented interfaces working as they are documented, but gives us some leeway to fix up bad decisions or unsupportable APIs. I think that the strategy that I've outlined should lead us in that direction, and allow us to release more often and with better communication about what users should expect to have changed. Does this answer your question? > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
