On Thu, 7 May 2015, jcf wrote:
I don't think that reflects a firm grasp of the nature of the problem. The issue is that
the "new thing" here is not the thing that the package's version number should
be describing in the first place. I don't care about the newness of AIO layout and
packaging, and I don't expect many others will either. People don't install Puppet for
its packaging. I do care about the versions of various components of the system, but not
everyone will, and anyway, we have already established that an AIO package's version
number is not a good vehicle for communicating information about versions of auxilliary
components. Focus on what's important. To your audience.
I am also pretty baffled that this is considered hard, or even a matter for
debate. Principle of Least Surprise, or just have the contents match the tin.
FWIW I find this argument pretty compelling and would like to advance the
version number of the next release of puppet-agent to '4.something'.
Our current thinking is that this will be a matched to the puppet version,
with an extra digit on the end of the version number that indicates component
revisions other than Puppet itself.
So specifically, the next release will be puppet-agent-4.2.0.0; a hypothetical
rev to include a not-very-hypothetical openssl update would be included in a
puppet-agent-4.2.0.1 package.
(We can't use the release field as suggested up-thread, because some packaging
systems don't view numbers not part of the 'version' field to be an upgrade.)
Does that align more closely with the least-surprising thing, to you?
Eric Sorenson - [email protected] - freenode #puppet: eric0
puppet platform // coffee // techno // bicycles
