Re: [DISCUSS] PIP-175: Extend time based release process

[Nicolò Boschi <bo...@gmail.com>]

Matteo,

Can you start the vote for this PIP?
We should start working on 3.0.0 soon and this PIP is required to
reach community consensus.

https://lists.apache.org/thread/d6rk2ntzwk8twznf82k7o6xgyb2k9s14

Thanks,
Nicolò Boschi


Il giorno mer 9 nov 2022 alle ore 09:37 Haiting Jiang <
jianghaiting@apache.org> ha scritto:

> Hi all,
>
> What's status of this PIP?
>
> There's an issue talking about fixable vulnerabilities in the latest
> release.
> https://github.com/apache/pulsar/issues/18348
>
> From what I see,  one of the problems is that we take too long to make a
> new release ( over 2 months for 2.10.2 ). Hopefully, this PIP could do some
> help on the issue.
>
> Thanks,
> Haiting
>
> On 2022/06/07 22:25:24 Matteo Merli wrote:
> > https://github.com/apache/pulsar/issues/15966
> >
> > --------
> >
> > ## Motivation
> >
> > In PIP-47 (
> https://github.com/apache/pulsar/wiki/PIP-47:-Time-Based-Release-Plan),
> > we have adopted a time-based release plan. This was the first attempt
> > at establishing a new principle on how releases should b
> >
> > The main two benefits of this approach have been:
> >
> >  1. Clarity for users and developers on when to expect a release
> >  2. Breaking a hard relationship between feature and release: a
> > particular feature will be included in the release if it is completed
> > in time. Otherwise, it will be bubbled up to the next release.
> >
> > The motivation for the current proposal is to extend the existing
> > process to address the issues that we have seen and that were left out
> > of the scope of PIP-47.
> >
> > ## Summary of existing issues in the process
> >
> > ### Short maintenance cycles for releases
> >
> > Since we're doing a 3 months release cycle, we are ending with 4
> > releases done per year, even though it's more close to 3 releases.
> >
> > There is a high cost to maintain a lot of old releases, backport bug
> > fixes, and security patches. In general, we actively support the last
> > 3 minor releases while continuing to develop the next release. E.g.,
> > 2.8, 2.9, and 2.10, while 2.11 is under development.
> >
> > The result is that a user adopting a particular release is forced to
> > upgrade in a < 1-year timeframe to keep up to date and use a supported
> > release. This timeframe is too short for many users as it imposes a
> > lot of forced upgrades, for which they are not prepared in terms of
> > available time and required effort.
> >
> > ### Live Upgrade/Downgrade compatibility path
> >
> > In Pulsar, we guarantee that users have a way to do live upgrades and
> > downgrades with zero downtime.
> >
> > This is very powerful because it gives them the freedom to upgrade to
> > a new release with the assurance of being able to roll back to the
> > previous release in case any functional or performance regressions are
> > encountered.
> >
> > Today, this compatibility is guaranteed across minor versions. Eg: I
> > can do  `2.7 -> 2.8 -> 2.7` as a live upgrade.
> >
> > What is not guaranteed is to "skip" releases. E.g.: `2.7 -> 2.9` might
> > work or not, but it's not guaranteed. In that case an intermediated
> > upgrade would be required: `2.7 -> 2.8 -> 2.9`.
> >
> > The reasons for which the "skip" upgrade might not work are multiple:
> >   1. Incompatible upgrade of some dependency (e.g., ZooKeeper) that
> > might not be compatible with an older version.
> >   2. Adoption of a new metadata format or data format on disk.
> >      Every time we introduce a new incompatible format change (outside
> > of a regular Protobuf field addition), we do it in a 2 steps way:
> >       - In a new release, we introduce the new feature/format,
> > disabled by default. The new release can read both old and new
> > formats, though it keeps writing the old format by default.
> >       - In a subsequent release, we change the default to the new format
> >
> > Note that this consideration is separate from the compatibility
> > between clients and brokers, where we ***never*** break compatibility.
> > The oldest available Pulsar client can still talk with the newest
> > Pulsar broker, and vice versa, a new client, will be perfectly fine
> > with an older broker (except the new features won't be working).
> >
> > ### Releases getting delayed
> >
> > Another problem we have been experiencing is that release cycles have
> > been stretching considerably. Part of this has been because we have
> > been reaching the end of the release window, preparing a candidate,
> > and then taking a long time to flush out all issues found at the last
> > minute in the new release.
> >
> > We need to ensure that we have a date set in stone to deliver the
> > release to users.
> >
> > ## Proposal
> >
> > The proposal to address the above issues is composed of 2 parts.
> >
> > ### 1. Establish Long Term Support releases
> >
> > We need to provide a way for users to quickly understand the expected
> > lifecycle timeline of a given release and for that timeline to be long
> > enough not to be a constant update mandate.
> >
> > At the same time, we need to ensure that we maintainers are not
> > spending all the time just maintaining a huge list of old releases.
> >
> > For that, we can use the established concept of "Long Term Releases" or
> LTS.
> >
> > We will perform LTS releases at a fixed cadence every 18 months, and
> > we will keep doing regular feature releases every 3 months as we're
> > currently doing.
> >
> > The LTS releases will be identified by being a `.0` version. For example:
> >  * `3.0` -> LTS
> >  * `3.1` -> regular release
> >  * `3.2` -> regular release
> >  * `4.0` -> LTS
> >
> > The major version bump will not carry any special meaning in terms of
> > "big features" included in the release or breaking API changes.
> > Instead, it would simply signal the type of the release.
> >
> > #### Compatibility between releases
> >
> > It will be guaranteed to be able to do a live upgrade/downgrade
> > between one LTS and the next one.
> >
> > For example:
> >
> >  * `3.0 -> 4.0 -> 3.0` : OK
> >  * `3.2 -> 4.0 -> 3.2` : OK
> >  * `3.2 -> 4.4 -> 3.2` : OK
> >  * `3.2 -> 5.0` : Not OK
> >
> > #### Release support expectation
> >
> > We will publish clear guidelines on the Pulsar website regarding the
> > expected timeline for which each release is supported and when the new
> > feature and LTS releases will be available.
> >
> > The support model will be:
> >
> >  * LTS
> >    * Released every 18 months
> >    * Support for 24 months
> >    * Security patches for 36 months
> >  * Feature releases
> >    * Released every 3 months
> >    * Support for 6 months
> >    * Security patches for 6 months
> >
> > This can be translated into:
> >    * We support the last 2 LTS releases and the last 2 feature releases
> >    * Security patches are provided for the past 3 LTS releases and 2
> > feature releases
> >
> > Users are therefore encouraged to stay in an LTS release until they
> > are ready to jump into the next LTS unless they want to have access to
> > some of the features included in the latest feature releases.
> >
> > ### 2. Introduce a code-freeze period in the release cycle
> >
> > To address the problem with delayed release cycles, we are introducing
> > a code freeze period that will give us time to stabilize the release
> > code while not blocking new changes from being merged into master for
> > the subsequent version.
> >
> > This code-freeze will only be adopted for LTS/feature releases, not
> > for any patch release.
> >
> > In a 3 months release cycle, the last 3 weeks will be marked as a code
> > freeze period. The release manager will branch off from master, and he
> > will be responsible for selecting the changes that will be
> > cherry-picked in the release branch.
> >
> > From the code-freeze point, to minimize the risk of delaying the
> > release, only bug fixes involving a regression of behavior compared to
> > a previous release should be allowed. Occasional exceptions will be
> > possible after higher scrutiny of the change.
> >
> > At the moment of the code freeze, the release manager will also
> > prepare a release candidate in the same way we are doing today.
> > Committers, contributors, and users will test this RC to detect issues
> > as early as possible.
> >
> > A formal vote by the PMC will not be required at this stage (though
> > any disagreement should be sent out ASAP).
> >
> > After 1 week, if there are any changes, the release manager will
> > provide a new RC release that the community will test again.
> >
> > After 1 more week, if there are any changes, a third RC will be
> > prepared, and this will be submitted to vote to the PMC. Otherwise,
> > the vote will be held on an earlier RC release if no issues are found.
> >
> > The last 1 week will be used for the voting process and for updating
> > Pulsar website and the blog post announcing the release, which should
> > (hopefully) happen on the scheduled day.
> >
> >
> >
> >
> > --
> > Matteo Merli
> > <ma...@gmail.com>
> >
>