Release/support cycle

[qwerty287]

This was already mentioned in #1780, but there wasn't really a discussion about this or even a decision.

Now that we published the first "really" stable release 1.0.0, we should think about how we proceed with new releases and how to support them. This mainly includes the question: When do we want to publish a new release, either after a specified time or after a specified number of merged PRs/features?
For point releases, we had that question internally once after a dependency update with security fixes, and we decided to publish the release immediately after merging such security-related PRs. We also need to decide if we define rules for releasing point releases if there are no security issues, just some bugs. I'd suggest here to treat critical bugs as security fixes and release them immediately, and if there was a long time (a few weeks?) no point release because there were no security updates/critical bugs, also create a release so bug fixes can be used.

Also, the second part of this issue is the support cycle: How long do we want to support releases with point releases containing bug and security fixes?

[6543]

My proposal:

• as for majour releases, I would say if there are breaking changes to the inner-cores of woodpecker, like the pipeline definition, we should bump.
• as for minor releases, if it requires user action to e.g. server-settings ... if we hit max 3 breaking changes and/or 5features
• as for patch releases, after some time if there are unreleased changes (e.g. 1week) or if it does acumulate enouth patches to be worth releasing. or asap on sec-fixes

as for maintaining: we should officially point out, that we only fix the current release branch but wellcome backports to older ones as long as there pipeline do work.

If there is a critical bug/sec issue we should consider the last release branch too if affected

[pat-s]

My 2 cents:

• I am a friend of scheduled point releases - especially when there is enough activity. Every 3 months is often a good interval. This removes the ever-returning question of "are we ready?" & "should we still wait for PR XY?". Especially due to the experiences with 1.0.0 here I am a bit afraid that without a fixed interval the release cycles might be too long 😅
• A point release can be a major bump if there is a breaking change. Don't be afraid of breaking changes WRT to version numbers!
• The problem with the above approach is that for important patches one would need to branch-off from the most latest release and only add the patches - otherwise all features that were merged in the meantime are also in the patch release and not bundled in the scheduled point release

[6543]

the last point I dont get ... as we do squash merge and cherry-picking

[zc-devs]

I am a friend of scheduled point releases - especially when there is enough activity. Every 3 months is often a good interval.

I agree with that. If we stick to features count, then there may be only major releases, because there is a lot of breaking changes (in my sense) and bugs just won't get released between majors. So, what's the point of semver then? Just use calendar versioning :) It's next on steroids (with changelog as was concerned in previous discussion).

as for minor releases, if it requires user action to e.g. server-settings ... if we hit max 3 breaking changes and/or 5features

I think breaking changes should not be released in minors. MINOR version when you add functionality in a backward compatible manner.

[pat-s]

the last point I dont get ... as we do squash merge and cherry-picking

In my idea you would treat fixes different than features. I.e. if two features are merged, than an important sec fix, a release is made with ONLY the sec fix and the features are only included in the next point release. Otherwise the fixed date of point release is not really making sense as new features get released during the rolling sec fix releases.

---

Should this become a poll among maintainers and the result will be binding for the project? Or more like a discussion and owners still decide what they want to do in the end?

@6543 @anbraten

[qwerty287]

In my idea you would treat fixes different than features. I.e. if two features are merged, than an important sec fix, a release is made with ONLY the sec fix and the features are only included in the next point release.

Isn't this our current approach with patch releases? They'll never contain new features, but security and bug fixes will be backported.

[zc-devs]

I.e. if two features are merged, than an important sec fix....

That's purpose of PATCH version, I think. Suppose, current last release is 1.0.0. Two features (non-breaking) are planned for 1.1 and merged. Than an important sec fix is going to 1.1 branch (obviously) and 1.0 also. Then 1.0 is going to release 1.0.1 immediately, but 1.1 is waiting for its schedule.

I agree with that. If we stick to features count...

Obvious, if there is no breaking change for planned major release date, then skip major and continue with minors.

[mzampetakis]

Pretty interesting discussion and a difficult decision.

I think the approach of @6543 here is a good starting point. However, it would be really helpful if there is a defined plan for the support cycle. The reason for this is that realising many patch versions and having to support back lots of minor versions might be pretty difficult/time consuming.

A possible solution to this could be that only the latest 3 minor releases are supported. This would unload some effort from patching but some users might prefer having a date-defined support cycle.

[pat-s]

A possible solution to this could be that only the latest 3 minor releases are supported. This would unload some effort from patching but some users might prefer having a date-defined support cycle.

Minor releases (usually) never get a backport. At least not in projects of this scale, we are not Hashicorp.
It's only about major versions and given the lack of features in 0.x, users should be encourage to upgrade anyhow (soon).

But even then, IMO it would also be fine to say "please go with the flow", i.e. expecting from users to update their instance at least 2-4 times a year?

[anbraten]

As updating to the next minor release should be no problem (no breaking change) I would only support the last minor.patch of the last major and maybe previous major versions.

So for example:

• 1.2.23 (newest overall version)
• 1.2.22
• 1.1.30
• 0.15.3 (previous major version)
• 0.15.2
• 0.14.0

[qwerty287]

@woodpecker-ci/maintainers

Since we are now just before releasing 2.0, we need to finally decide on this:

1. Main question I have is, if we still backport bug and security fixes in the future or use a "rolling" approach by just releasing the main branch if necessary, with the correct major/minor/patch bump. This would also mean: Merging two features and after this a security fix, only a new major version is released, but no minor.
2. Which time cycle?
3. If we backport stuff, for which versions do we backport? Majors on minors?

[qwerty287]

Just another question from matrix: What about RCs?

All in all though we should somehow write down/define what the policy is, so users at least know what we concluded here 😃

The issue about this is more that we didn't really have a conclusion yet that's reviewed by all maintainers yet I think 🙃

[xoxys]

I am for at least one RC for major versions that is communicated across our channels as well, to at least give users the chance to test it and report issues before we tag the final release.

[qwerty287]

I agree. Let me sum up what we agreed on until now:

1. No backports, current main is released with the correct version in any case
2. RC before majors (and maybe minors?)
3. time-based schedule (e.g. once a month and of course critical bug and security fixes are released at any time - but they'll include new features if they were already merged into main)

[zc-devs]

Merging two features and after this a security fix, only a new major version is released, but no minor

Tadam! Major with secfix is broken (just for example 2737). Or one have to rename pipelines to steps / reconfiguring, something like that.

I don't know... I like current approach... but I'm not a maintainer :)

---

OK, not necessary to backport to previous major after releasing new, but I like current branches structure and releasing approach.
main is the the next major, I always push to the main first. Then if changes are not braking & I want, I push to minor. If security - straight to the current patch.
As a user I have supported stable version. Also the changes that aren't going to the current minor have chance to stabilize before the next major release.

[qwerty287]

Tadam! Major with secfix is broken (just for example 2737). Or one have to rename pipelines to steps / reconfiguring, something like that.

Just let me comment in this again (I know, the comment is very old already): This is something we definitely wouldn't do.

1. If there are already breaking changes, we'll backport the security fix.
2. We'll try to hold back breaking changes anyways so we don't release a lot of majors in a short period of time just containing one breaking change each.