On Friday, April 24, 2015 at 12:44:08 PM UTC-5, Vince Skahan wrote: > > On Thursday, April 23, 2015 at 3:44:35 PM UTC-7, jcf wrote: >> >> There is actually nothing in semver that precludes co-terming major >> release versions, and less that precludes "--version" from both >> displaying the local package version, AND the release number targeted by >> said package if you disagreed with the first point. This is one of those >> circumstances where being pedantic means you reduce understanding, not >> increase it. >> > > Agree. >
Yes, but I think there's a combination of problems here. Let's take puppetserver first, because in some ways it's easiest. The version of puppetserver in the puppetserver-2.0.0 packages really is 2.0.0, thus software version code and package version code are consistent. The issue is that puppetserver 2.0.0 implements version 4.0.0 (I think) of "Puppet", where "Puppet" these days means the DSL, plugin API, and built-in type and function libraries. This is roughly analogous to version 31 of Firefox handling version 5 of HTML, but more confusing because it's new that there is a split between software version and -- I'm not even sure what to call it, but maybe "framework version". Inasmuch as puppetserver is taking over from the older Ruby implementation of the master, it may be that these numbers can be reconciled in the future. (See also below.) The puppet-agent package is where the real fun starts. As best I can determine, the version number of the puppet-agent package is associated with the overall all-in-one installation image and packaging, as opposed to the software packaged within, the central piece of which is the Ruby implementation of the Puppet software (version 4.0.0 of that software in the puppet-agent-1.0.0 package). I do not understand this decision, as it seems to fly in the face standard package versioning practice. That aspect of it could certainly be fixed, however -- it should not produce any great difficulties to bump up the version number for the package to correctly agree with the version of the packaged software. Then there's the question of standalone software packaged together with the agent, and the version numbers of those programs. In truth, I don't think the version number mismatch is a significant issue there if you accept all-in-one packaging to begin with. In my experience, it's pretty common for AIOs to bundle software with different version numbers, but it is unusual for such an AIO to be versioned differently than the bundle's focal software. I think this issue would be substantially mitigated just by making the version number of the puppet-agent package in fact match the version of the puppet agent software contained within. > > What I'm looking for is clarity for the users. What is there now is > beyond unclear. > > The problem as I see it is bundling. Puppet is grouping standalone > components into an aggregate 'release' of something bigger. The pieces > have versions that are far different from the aggregate. Each piece's > --version string doesn't even match the version of the rpm they were > bundled into. That is just wrong. > As you have seen, I somewhat agree. For what it's worth, I raised a bit of a stink a few months ago in the developers group about PL's decision to make Puppet 4 *depend* on an AIO-style installation image, but I was unable to persuade much of anyone. Given PL's decision to go that direction, AIO packaging is a natural result, albeit an unnecessary and unwelcome one. > > Put yourself in the user's shoes: > > - I think I'm running puppet open source 4.0.0 including both server > and agent > - there is a puppetserver-2.0.0 there, and a puppet-agent-1.0.0 there > - geez, I must be YEARS behind current ! > - so I look in /opt/puppetlabs/bin and see five binaries, none of > which have --version = 4.0.0 or even 'close' to the rpm version they came > from > - and that is clear 'how' exactly ? > > The 'puppet' binary reports version 4.0.0, which is consistent with the idea that you're running that version of Puppet. If I wanted to verify which version of puppet I was running, that's certainly the binary I'd look to. As I said, though, the package in which it is provided should also bear that version number. That puppetserver's version doesn't match the Puppet framework version it supports certainly seems more confusing to me. > My suggestion would be: > > - puppetserver rpm should be 4.0.0 for puppet release 4.0.0 > - puppet-agent rpm should be 4.0.0 for puppet release 4.0.0 > > The latter, for sure. The former would be desirable, too, but only in conjunction with puppetserver's software version actually being bumped up to 4.0.0. > And to me I'd add: > > - everything in a typically public-interface directory (not a bundled > ruby version, for example) that is therein and supports a --version should > return a version reflecting the rpm version they were packaged in somehow > that is user obvious. > > or if you can't do that, bundle each of them into their own individually > versioned rpms (ie. facter-2.4.3) and have puppet-agent require multiple > rpms. > > I would be all for packaging the (semi-)independent components separately, each in a package with version number matching the packaged software's version number. I would be even more for ensuring that none of it depended on being installed in an AIO-style image, but that's a separable issue. If the intention is for any of the core components (agent and server, more or less) to continue to be developed on their own cycles, then it might be appropriate to add an additional version number to associate the binaries with the puppet framework version with which they are associated. For example, one might then have # puppetserver --version --framework-version puppetserver version: 2.0.0 Puppet framework version: 4.0.0 John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/b9949b77-947c-43b9-aa9e-1dcbf7f72858%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
