Issue #21427 has been updated by eric sorenson.
The changes for this ticket cause errors submitting reports when a 3.3 agent talks to a 3.2 master. Because this change was part of a security fix, it's not a great idea to make the compatibility mode selectable by a setting; however, there's a legitimate concern (which Moses eloquently expressed in PP-281) that releasing such a change in a 3.3 release is a violation of semantic versioning guarantees. Talking through this in #puppet-dev and around the office, seems like there's two real options, each with their own pros and cons. (Reverting the change because we can't figure out how to release it doesn't make any sense) ### Release as 4.0 _Pro_: strict interpretation of semver supports this "Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API." The major number bump will convey meaning to people that they need to be careful with upgrading. _Counter-Pro_: Puppet's internal network communications do not constitute public API. People who follow master-first upgrade instructions will not see this. People who do not follow upgrade instructions will not have their infrastructure stop working (as they would if catalog requests failed to work). _Con_: If this is the only backwards-incompatible change that's in Puppet 4, we'll release Puppet 5 before the end of the year, which seems arbitrary and poorly-planned. _Counter-Con_: It "seems" that way because it would actually be that way, but it's better (in a utilitarian sense: better fulfilling the values of honesty and transparency) to take the lumps than pretend otherwise. ### Release as 3.3.0 _Pro_: In Andy's words, "this is analogous to a C program that requires glibc 2.18 in a new version where before it could work with 2.17 is required to bump the major version." _Counter-Pro_: that analogy is only true if the program and library are distinct to one another, rather than a single unit. _Con_: People who directly use Puppetlabs repos for provisioning will see errors as they did when we released 3.0, except without a version-number indication of why. _Counter-con_: Incrementing the version number will not actually solve the problem for those people; if that's the primary reason it's only a CYA move not a substantive change to help them. ---------------------------------------- Feature #21427: Deprecate YAML for network data transmission https://projects.puppetlabs.com/issues/21427#change-97027 * Author: Andrew Parker * Status: Merged - Pending Release * Priority: Normal * Assignee: Patrick Carlisle * Category: * Target version: 3.3.0 * Affected Puppet version: * Keywords: * Branch: https://github.com/puppetlabs/puppet/pull/1734 ---------------------------------------- YAML serialization has ended up being slower than P/JSON and opens the system up to a number of security flaws. It is time to leave YAML behind on the network layer. We'll continue to keep it for storing some information on disk. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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-bugs. For more options, visit https://groups.google.com/groups/opt_out.
