I find this scheme confusing. I would be hard pressed to explain the difference between :6.7, built from *source*, and :6.7.0, built from a *package*. I also don't think it's clear that :6.7 would advance past :6.7.0 in time.
I like the :edge and :latest tags. But I think I'd be happier with some kind of "nightly" specification on the source version (unless I've misunderstood). Maybe :6.7-nightly. That would make it more clear to me that it's a frequent build of the 6.7 branch, while 6.7.0 is a pinned version. On the whole though, I think it's a good change. Thank you! On Tuesday, October 15, 2019 at 2:56:49 PM UTC-4, Morgan Rhodes wrote: > > Hi all, > > *tl;dr* - We're trying to make the versioning scheme for our containers > more intuitive, changes summarized in the table below, see more details at > https://github.com/puppetlabs/puppetserver/pull/2188 > > build typecurrent tagnew tag > from source puppet/puppetserver:6.7.0 puppet/puppetserver:6.7 > from source (latest) puppet/puppetserver:latest puppet/puppetserver:edge > from package n/a puppet/puppetserver:6.7.0 > from package (latest) n/a puppet/puppetserver:latest > *Versioning* > > For a while now, our containers have included a package built from source > and versioned based on the most recent tag to the repo. While we still > think building from source provides value to our users, it's become clear > that they also need a way to pin to a specific, released version of > puppetserver and count on that container not being updated. To address > this, we're changing the versioning scheme for our container builds. > > When we build images from source, those images will be versioned with X.Y > versions based on the latest tag on master. So, for example, the current > image versioned puppet/puppetserver:6.6.0 would move to > puppet/puppetserver:6.6. This tag will continue to have rolling updates > until the next X or Y release. If you want to follow whatever the latest > version of the image from source is, you will want to pin to > puppet/puppetserver:edge. > > We will also start building and shipping images when puppetserver is > shipped publicly. These images will be tagged with an X.Y.Z version that > will match the version of puppetserver installed on that image. This tag > will not receive any updates. If you want to follow the latest released > version of puppetserver, you will want to pin to puppet/puppetserver:latest. > > *Other Changes for the puppetserver images* > > We are also looking into removing the puppetserver-standalone image. I've > added a `USE_PUPPETDB` environment variable that can be set to false when > running the puppetserver image to have the same behavior as the current > puppetserver-standalone image. > > *Questions / Comments / Concerns?* > > Please leave comments at > https://github.com/puppetlabs/puppetserver/pull/2188 or respond here. > > -- > Morgan Rhodes > Release Engineering > [email protected] <javascript:> > she/her/hers > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/3c910a1c-3e50-43ed-a554-57fceb48b7d1%40googlegroups.com.
