Hi Vince and John, thanks for this feedback. There's quite a few things under discussion in this thread but I think we can unpack them.
On Monday, April 27, 2015 at 9:34:13 AM UTC-7, jcbollinger wrote: > > > > 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.) > Puppet Server 2.0 doesn't implement any of the "DSL, plugin API, type/function libraries" at all. All of those things exist independently of puppet server, inside of the "core" Puppet codebase. You can assure yourself of that by installing only the puppet-agent-1.0 AIO (or just puppet-4.0.0.tar.gz for that matter) and running 'puppet apply', 'puppet master', etc etc, without any puppet-server whatsoever. But your argument is not invalid! There *is* a piece which ties Puppet Server 2.0 to Puppet 4, and that is the agent<->master network API. So you could totally advance the idea that there should be some version-related coupling between those two projects. This is implicit right now (or rather, it's expressed in package dependencies and text documentation) and I understand your and Vince's desires to have this made more explicit, by expressing it directly in the version numbers of each project. The "Framework version" you're describing is exactly the concept we're trying to express with the Collections repository (for future Googlers' context, the explanatory blog post is at: https://puppetlabs.com/blog/welcome-puppet-collections ). PuppetDB also has some dependency tendrils, too, but its versioning is totally decoupled from Puppet's. > 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. > I think this arose from a desire to express the versioning of the AIO as a semver number which tracks the collection itself, independently from the versions of the constituent projects. Since there is ruby, facter (both flavours!), mcollective, hiera, augeas, it seemed wrong to pin the puppet-agent number to puppet-the-project. But perhaps it was an error to have a non-puppet-centric view of the world, since it's true that the *purpose* of all those other things is really to deliver Puppet in a batteries-included, supportable way. > 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. > I think this and Vince's example below make sense at the initial release point, but as we found when we attempt to match PE's version number to its Puppet component, it very quickly degenerates into incoherence. As an example, if it started out at puppet-agent-4.0.0 to match puppet-4.0.0, but the only change in the next AIO package is to incorporate a feature update in Facter (a hypothetical 2.5.0), we'd want to reflect that feature update in puppet-agent-4.1.0. But should that then trigger a release of a puppet-4.1.0 *even though nothing has changed in puppet*? > 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. > Well, it's more that Puppet Labs' packaging for Puppet 4 is an AIO-style installer, not that Puppet 4 depends on AIO inherently. This might be parsing too tightly, but I want to emphasise that anybody could do this to build a standalone Puppet 4 RPM: rake package:rpm if the AIO is truly anathema. We're also working to open-source the packaging toolchain, so if it's not so much the idea but the particular component versions (or the installation root, as I've gotten some feedback hardcoding /opt doesn't work for some people), you could roll your own. > 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. > Right, puppet --version does return 4.0 so, Vince, I'm not sure what you saw. If some or all of the (Collections repo, Puppet-Agent, Puppet-Server, Puppet) said "4", would things fall into place cognitively? How would you expect them to change over time? I.e should they all update in lockstep? If not, how much drift would cause the linkage between them to no longer make sense? > 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 > > We've clearly done a less-than-stellar job at either (or both!) understanding what people outside PL walls expect with regard to versioning, or communicating why the numbers landed the way they did. Let's think through changes to the current scheme in the context of the next 9-12 months of major/feature/patch releases and figure out what's going to work best. --eric0 -- 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/f9434a5d-8deb-4025-a822-1daa4723cd65%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
