Major release

[anbraten]

We should define a release cycle for major versions. The idea to release 3.0.0 next #3957 is currently somehow ignoring that users will have to prepare for some braking changes. For larger deployments with multiple users & repositories (There are deployments with >1000 repos 😉) this requires some time.

Especially changes to pipeline configs take some time. To streamline this process we started adding some deprecation notices to the pipeline compiler some time ago. Therefore I propose defining a major release cycle of > 12 months (would result in a release date of earliest Nov 23, 2024 for 3.0.0). In addition every change that requires interaction by the Woodpecker users (not only admins) should be announced / marked as deprecated latest some time (proposing 3 months) before removal to provide enough time for admins to update to latest minor versions and users to notice / be notified by this change.

Having some minimum duration for major will also allow the maintainers / contributors to propose changes that should definitely be considered in the next version.

[qwerty287]

We should define a release cycle for major versions. The idea to release 3.0.0 next #3957 is currently somehow ignoring that users will have to prepare for some braking changes. For larger deployments with multiple users & repositories (There are deployments with >1000 repos 😉) this requires some time.

Especially changes to pipeline configs take some time. To streamline this process we started adding some deprecation notices to the pipeline compiler some time ago. Therefore I propose defining a major release cycle of > 12 months (would result in a release date of earliest Nov 23, 2024 for 3.0.0).

I don't really get how this is different from now. If we now publicly announce that the next release will be 3.0, users will have about one month to migrate. If we say that the next major must be at least 12 months after the last one, there still is no difference in this. If we say the next major release is exactly 12 months after the last, everyone would know when the next major comes, but it doesn't really help you in migrating your repos.

In addition every change that requires interaction by the Woodpecker users (not only admins) should be announced / marked as deprecated latest some time (proposing 3 months) before removal to provide enough time for admins to update to latest minor versions and users to notice / be notified by this change.

About changes to pipeline configs, this would be fine for me, but about changes for admins, it depends on the change.
Most admin changes just mean "rename an env var" or something similar, so this should not be a problem to do in a few minutes and does not need a few months to be deprecated before removal.

Also, even if we would introduce this rule, I don't get how this conflicts with a breaking release in the 12 months after the last one. You could just keep some deprecations without removal and remove them in the next major.

Having some minimum duration for major will also allow the maintainers / contributors to propose changes that should definitely be considered in the next version.

This I definitely don't get. How is this related here? You can always make these suggestions, and we can always want with a release until a certain PR is merged. We did that pretty often already.

So I'd say a fixed time like 3 months a deprecation has to stay at least is fine, but to fix the major releases is useless. We also have to note that every deprecation makes our code more complex and removing it makes it much simpler in most cases.

[6543]

I remember that from v0.15.x to v1.0.0 we took quite a while and I often had to say ... you should use next as it is not jet released ... so a more rapid release schedule as we have now is a good. As the bump from 1.0.0 to 2.0.0 was a bit short I think 7months are quite OK.

So I would not specify strict dates as nobody works on WP full time btw ... but rather ranges.

So I'm OK to have a block majour versions to be made before 1/2year to the last one but it could be longer if no more than a few (2...3) breaking things are scheduled. blocking it for 1year is to much in my opinion.

What we could do is to have a release branch in times where a majour version is in development, to be able to still release new versions, if needed ... If we do it the other way around and hold breaking changes till we wana do a majour version we get a lot of conflicts etc ...

[lafriks]

Hopefully we come to the phase to stabilize that at least pipeline definitions are stable to not have breaking changes and if just for server side it really does not matter than how often we release major version

[qwerty287]

Yes, and I think only #2473 and #3411 are breaking changes we're currently planning.

[zc-devs]

Sorry for "spam" here and there, I just want to understand the rules and a flow.
Follow up of #3918 (comment) and #3997 (comment).

Should #3397 was opened before 2.7.0 to be eligible for 3.0? Should PR was opened also or Issue is enough?
Suppose, I waited for next major to be announced, because I didn't want to waste time to make a PR into branch, which will become far outdated before actual merge. How should I know, that after 2.7 next major is coming? What is the flow?

Besides, reading #2780:

Deprecated parts have to be announced in the release notes

Did I understand correctly, that 7 opened/drafted PRs from the deprecation tracker are not going to 3.0 as well as #2473, #3411?

[qwerty287]

See my comment in #3997 for some explanation - I hope that helps.

And yes, this is not fully clear yet.

For 3.0, we'll just do everything listed here and everything else except pipeline config changes (as updating them is hard and time-consuming if you have a lot of repos).

I think we should write some formal clarifications for this after 3.0.

And the other point we need to improve is our communication. Yes, deprecations must be announced, and that the next release will be major is also something that can be helpful to know.