Release cadence

[sparkiegeek]

The one and only release of Pebble is v1.2.0 back in May. As of the time of writing there have been 46 commits, comprising 5,319 additions and 2,418 deletions of lines of code.

v1.2.0...master

(Will Pebble use SemVer or CalVer?)

Regardless I believe Pebble owes its users and consumers a release cadence beyond 1 in infinity :)

[jnsgruk]

Hey!

@jameinel and I were actually talking about this today.

@benhoyt - I think we should settle on a release plan similar to ops - which translates to roughly one point release per month, or a patch release if only minor changes are incurred. Patch releases can also be cut in between to address specific bugs.

I think we should wait until #267 has landed, and cut a 1.3 that supports log forwarding. I don't have a solid timeframe on that - so we could consider doing a 1.2.1 release right now to cover all commits up to the point where the initial log forwarding PR landed (#256).

Thoughts? :)

Edit: actually given the service context stuff we added and volume of changes, perhaps we should do a 1.3.0 now and a 1.4.0 when we have log forwarding.

[sparkiegeek]

@jameinel and I were actually talking about this today.

Heh - well I was inspired to finally file it after seeing chat

@benhoyt - I think we should settle on a release plan similar to ops - which translates to roughly one point release per month, or a patch release if only minor changes are incurred. Patch releases can also be cut in between to address specific bugs.

I think we should wait until #267 has landed, and cut a 1.3 that supports log forwarding. I don't have a solid timeframe on that - so we could consider doing a 1.2.1 release right now to cover all commits up to the point where the initial log forwarding PR landed (#256).

Well i don't think a maintenance release is correct. 00bcd1f seems chunky enough to warrant a 1.3.0 (log forwarding being 1.4.0)

Edit: edit-sniped!

[sparkiegeek]

I think Juju can help keep Pebble honest by refusing to ship unreleased versions

[benhoyt]

@sparkiegeek Very much agreed we want this. It's mainly a matter of me or someone making a bit of time! I previously added this to my next cycle roadmap (also fixing the related issue #225), but it seems like there's a fair bit of noise about it and it needs to be done sooner. :-) I would much prefer semver over calver, or benver or adamver for that matter. :-)

Issue #225 is the one where we're not including the version number in the source code of the released tag, which causes the version in Juju and versions installed using go install to show "unknown" when you run pebble version. I think that should be fixed soon as well, though it's not a hard requirement for additional versioned releases.

@jnsgruk Given that Pebble is a dependency of Juju and other projects, will a monthly release cadence be too infrequent? I'm thinking even weekly might be good. Then again, maybe monthly + patch versions as appropriate would work.

Edit: actually given the service context stuff we added and volume of changes, perhaps we should do a 1.3.0 now and a 1.4.0 when we have log forwarding.

I fully agree. There's been many changes and several small new features since 1.2.0. I think we should do 1.3.0 now and another when we have log forwarding fully baked. I can go ahead and do that if we're all agreed?

[benhoyt]

When I ship v1.3.0 I'd like to include the internal version number in the source, by doing this manually (later we can automate it).

Draft release notes:

---

Pebble version v1.3.0 includes several notable features and fixes as well as many CI and testing improvements, and a significant refactoring of the Pebble internals.

What's Changed

Notable user-facing features and fixes:

• fix: pebble exec and "exec" health checks inherit environment from daemon by @rebornplusplus in fix: pebble exec and "exec" health checks inherit environment from daemon #234
• fix: allow non-root user to specify current user/group when running commands by @benhoyt in Allow non-root user to specify current user/group when running commands #239
• feat: add support for services to configure working directory by @benhoyt in Add support for services to configure working directory #245
• feat: add "service context" support for exec and health checks by @benhoyt in Add "service context" support for exec and health checks #246
• fix: do not inherit HOME and USER env vars from pebble daemon environment by @shayancanonical in Do not inherit HOME and USER env vars from pebble daemon environment #262
• fix(servstate): use WaitDelay to avoid Command.Wait blocking on stdin/out/err by @benhoyt in fix(servstate): use WaitDelay to avoid Command.Wait blocking on stdin/out/err #275
• feat(logstate): log forwarding implementation II by @barrettj12 in feat(logfwd): log forwarding implementation II #256

Refactoring and CI improvements:

• refactor: Pebble internals into an exportable package by @anpep in Refactor Pebble internals into an exportable package #226
• ci: allow Pebble to be packaged as a snap by @cjdcordeiro in allow Pebble to be packaged as a snap #179
• ci: promote snap to candidate on every release by @cjdcordeiro in ci: promote snap to candidate on every release #255
• cli: public commands API by @anpep in cli: public commands API #232
• build: update Go version to 1.20 by @barrettj12 in Update Go version to 1.20 #171
• ci: build Pebble snap with Go 1.20 by @cjdcordeiro in Build Pebble snap with Go 1.20 #271
• feat(daemon): allowing adding external http handlers by @paul-rodriguez in daemon: allowing adding external http handlers #265
• feat(overlord): allow adding external managers by @paul-rodriguez in feat(overlord): allow adding external managers #273
• feat(cli): enable extended client access by @anpep in feat(cli): enable extended client access #285
• feat(daemon): daemon access for API extensions by @flotter in feat(daemon): daemon access for API extensions #293

New Contributors

• @sparkiegeek made their first contribution in Fix broken link in HACKING.md #227
• @cjdcordeiro made their first contribution in allow Pebble to be packaged as a snap #179
• @paul-rodriguez made their first contribution in daemon: allowing adding external http handlers #265
• @shayancanonical made their first contribution in Do not inherit HOME and USER env vars from pebble daemon environment #262

Full Changelog: v1.2.0...v1.3.0

[jnsgruk]

I fully agree. There's been many changes and several small new features since 1.2.0. I think we should do 1.3.0 now and another when we have log forwarding fully baked. I can go ahead and do that if we're all agreed?

Yes please, let's get a 1.3.0 released.

Given that Pebble is a dependency of Juju and other projects, will a monthly release cadence be too infrequent? I'm thinking even weekly might be good. Then again, maybe monthly + patch versions as appropriate would work.

I think we should aim for a roughly monthly point release, but we should be comfortable releasing patch releases on a more regular cadence as required - even if that means weekly or for a specific fix that a Juju release needs :). We don't need to be religious about it - if we happen to land a major feature 2 weeks after a point release, we can just release a new point release.

[benhoyt]

Sounds good -- I'll tag and ship v1.3.0 on Monday.

[benhoyt]

v1.3.0 released! I did the "edit version number in source code" dance so that this works too (though of course I'd like to automate that later):

$ go install github.com/canonical/pebble/cmd/[email protected]
go: downloading github.com/canonical/pebble v1.3.0
$ pebble version --client
v1.3.0

So from here on we'll go with a monthly release cadence plus patch releases as necessary.