You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pulsar.apache.org by Matteo Merli <ma...@gmail.com> on 2022/06/07 22:25:24 UTC
[DISCUSS] PIP-175: Extend time based release process
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>
Re: [DISCUSS] PIP-175: Extend time based release process
Posted by 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>
> >
>
Re: [DISCUSS] PIP-175: Extend time based release process
Posted by Haiting Jiang <ji...@apache.org>.
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>
>
Re: [DISCUSS] PIP-175: Extend time based release process
Posted by Matteo Merli <ma...@gmail.com>.
--
Matteo Merli
<ma...@gmail.com>
On Wed, Jun 8, 2022 at 12:33 AM Haiting Jiang <ji...@apache.org> wrote:
>
> > I was actually not thinking of changing the denomination of 2.11. On
> > one hand, it could make sense for being the first Java 17 release, but
> > on the other, we'd be releasing 2 LTSs super close between each other
> > and we'd have to support 1 release more for the time being.
> >
> > I'd like to hear more opinions here :)
>
> It's a little confusing here, if 2.10 is LTS for being the last Java 8 release,
> will there be feature release for 2.10 LTS, and 2.10.x are both feature release and patch release?
When we say 2.10 is LTS, it would mean that we are going to make patch
releases (2.10.1, 2.10.2, ...) with bug fixes and security updates for
a longer period of time. No new features will be added in 2.10.x
Re: [DISCUSS] PIP-175: Extend time based release process
Posted by Haiting Jiang <ji...@apache.org>.
> I was actually not thinking of changing the denomination of 2.11. On
> one hand, it could make sense for being the first Java 17 release, but
> on the other, we'd be releasing 2 LTSs super close between each other
> and we'd have to support 1 release more for the time being.
>
> I'd like to hear more opinions here :)
It's a little confusing here, if 2.10 is LTS for being the last Java 8 release,
will there be feature release for 2.10 LTS, and 2.10.x are both feature release and patch release?
Thanks,
Haiting
On 2022/06/07 23:39:23 Matteo Merli wrote:
> > > 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.
> >
> > Is 2.7 EOL? If so then we need to announce it explicitly.
>
> Actually, I was wrong. PIP-47 says the last 4 releases so 2.7 would be included.
> The point though still remains in that there's nowhere in the website
> where a user could check until when the 2.7 release is going to be
> supported.
>
> > > We need to ensure that we have a date set in stone to deliver the
> > > release to users.
> >
> > I would like the new plan to address the delays in cherry picking changes. These must never wait until a release is being made. We must keep these up to date. If someone marks a PR for an older release then they are volunteering to do the cherry pick within a few days. We need to be prepared for a 0-day security release.
>
> I agree that this is a problem, though I'd prefer to keep it in a
> separate proposal, specifically targeted at the process for patch
> releases, to avoid putting too many things into a single discussion.
>
> > > 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.
> >
> > From our existing release what is LTS?
>
> Good point, as we discussed earlier, 2.10 should be marked as LTS for
> being the last Java 8 release. I'll update the text to reflect this.
>
> > Does this mean that you are proposing the current Master as release/3.0 or will it remain 2.11?
>
> I was actually not thinking of changing the denomination of 2.11. On
> one hand, it could make sense for being the first Java 17 release, but
> on the other, we'd be releasing 2 LTSs super close between each other
> and we'd have to support 1 release more for the time being.
>
> I'd like to hear more opinions here :)
>
> > > 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
> >
> > Are those times since the initial release? It would be helpful to have a swim lane diagram.
>
> Yes, from the initial release (eg: 3.0.0) and yes we would have a
> clear diagram on the website.
>
> > > 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
> >
> > Please note that in the event of a security release that PMC members will generally need to do these in secret.
>
> No changes about that. This is only to set the user expectation for
> how long they can expect the security patches.
>
> It doesn't change a comma on the PMC process of discussing such
> releases, nor it would prevent doing additional security releases
> outside of the "guaranteed" window.
>
> > What is the plan for bug fix / security releases on say 3.0?
>
> Since 3.0 would be LTS, based on the above-proposed table: 2y for bug
> fixes - 3y for security patches
>
Re: [DISCUSS] PIP-175: Extend time based release process
Posted by Neng Lu <fr...@gmail.com>.
1. We can compose some charts/tables as https://endoflife.date/python on
the Pulsar website to help people understand the time frame.
2. Regarding the LTS release proposal, one thing I need some clarification
is will the LTS release include major new features compared to last release?
For example, in the following releases, is 4.0 basically the same as
3.2 except it's supported longer or 4.0 has new major features than 3.2?
3.0 <- LTS
3.1
3.2
4.0 <- LTS
On Wed, Jun 8, 2022 at 4:45 PM Michael Marshall <mm...@apache.org>
wrote:
> > 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.
>
> It's a frequent point of discussion to debate which bug fixes are
> urgent enough to trigger a new RC candidate.
>
> I propose that we try to set guidelines now so that we can rely on
> them when issues come up.
>
> In my opinion, net new bugs that were introduced in the version should
> be fixed. Bugs that are not new, should not trigger a new RC, unless
> there is general consensus (however we define that) that the bug is
> sufficiently bad that we should trigger a new RC.
>
> If a bug is discovered during the RC testing period and it is not
> fixed, we should note this in the release notes for the version under
> a "known issues" section. This way, users of the impacted feature may
> decide to delay upgrading, while users that do not rely on the feature
> will have confidence upgrading. The main goal here is to ensure that
> we don't miss release deadlines, as Matteo just mentioned, and to give
> our users confidence when upgrading.
>
> Performance regressions are another issue that will arise. Dave Fisher
> has been working extensively on building out performance testing
> infrastructure to measure many Pulsar features. I expect that he (or
> someone else doing performance testing) will find degraded performance
> for some feature in the future. I think we should have a general rule
> of thumb that some percent regression (maybe 10%?) is serious enough
> to trigger a new RC. A percent might not be the only measure. If we
> have absolute metrics, like that a Pulsar cluster of x size must be
> able to handle y topics, that might be meaningful, too.
>
> What do others think?
>
> - Michael
>
> On Wed, Jun 8, 2022 at 2:26 PM Matteo Merli <ma...@gmail.com>
> wrote:
> >
> > > Schedules always slip. Would you say that if the 3.x feature releases
> take too long with these hypothetical dates that 3.5 would be dropped in
> order to release 4.0 on schedule?
> >
> > Yes, there needs to be clarity for the users on when releases are to
> > be expected, even more so for LTS releases. And while it's true that
> > there are always delays, we have a lot that we can do to try to
> > minimize it. (eg: having a public deadline to hit will help in getting
> > everyone on the same page).
>
--
Best Regards,
Neng
Re: [DISCUSS] PIP-175: Extend time based release process
Posted by Michael Marshall <mm...@apache.org>.
> 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.
It's a frequent point of discussion to debate which bug fixes are
urgent enough to trigger a new RC candidate.
I propose that we try to set guidelines now so that we can rely on
them when issues come up.
In my opinion, net new bugs that were introduced in the version should
be fixed. Bugs that are not new, should not trigger a new RC, unless
there is general consensus (however we define that) that the bug is
sufficiently bad that we should trigger a new RC.
If a bug is discovered during the RC testing period and it is not
fixed, we should note this in the release notes for the version under
a "known issues" section. This way, users of the impacted feature may
decide to delay upgrading, while users that do not rely on the feature
will have confidence upgrading. The main goal here is to ensure that
we don't miss release deadlines, as Matteo just mentioned, and to give
our users confidence when upgrading.
Performance regressions are another issue that will arise. Dave Fisher
has been working extensively on building out performance testing
infrastructure to measure many Pulsar features. I expect that he (or
someone else doing performance testing) will find degraded performance
for some feature in the future. I think we should have a general rule
of thumb that some percent regression (maybe 10%?) is serious enough
to trigger a new RC. A percent might not be the only measure. If we
have absolute metrics, like that a Pulsar cluster of x size must be
able to handle y topics, that might be meaningful, too.
What do others think?
- Michael
On Wed, Jun 8, 2022 at 2:26 PM Matteo Merli <ma...@gmail.com> wrote:
>
> > Schedules always slip. Would you say that if the 3.x feature releases take too long with these hypothetical dates that 3.5 would be dropped in order to release 4.0 on schedule?
>
> Yes, there needs to be clarity for the users on when releases are to
> be expected, even more so for LTS releases. And while it's true that
> there are always delays, we have a lot that we can do to try to
> minimize it. (eg: having a public deadline to hit will help in getting
> everyone on the same page).
Re: [DISCUSS] PIP-175: Extend time based release process
Posted by Matteo Merli <ma...@gmail.com>.
> Schedules always slip. Would you say that if the 3.x feature releases take too long with these hypothetical dates that 3.5 would be dropped in order to release 4.0 on schedule?
Yes, there needs to be clarity for the users on when releases are to
be expected, even more so for LTS releases. And while it's true that
there are always delays, we have a lot that we can do to try to
minimize it. (eg: having a public deadline to hit will help in getting
everyone on the same page).
Re: [DISCUSS] PIP-175: Extend time based release process
Posted by Dave Fisher <wa...@apache.org>.
> On Jun 8, 2022, at 11:44 AM, Matteo Merli <ma...@gmail.com> wrote:
>
> On Tue, Jun 7, 2022 at 10:14 PM PengHui Li <pe...@apache.org> wrote:
>>
>> I'm not sure I fully understand the LTS release and feature release.
>>
>>> 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
>>
>> In this example, we can only introduce new features in 3.1 and 3.2,
>> and 3.1.x and 3.2.x should be the patch release based on the feature
>> release?
>
> Exactly, that aspect won't be changed. I will clarify more in the document.
>
>> We can have one patch release for a month.
>>
>> 3.0.x is the LTS release that will support at most three years.
>> After we have 4.0 LTS release, we will still support 3.0.x TLS for at least
>> 18 months.
>> And 4.0 TLS will have all the new features from 3.x
>
> Correct.
>
>
>>> 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
>>
>> Does this mean we can introduce new features in 3.x even if we have 4.x?
>> And how many patch releases for the feature releases we will support,
>> such as 3.1.x, 3.2.x, 3.3.x, 4.1.x, 4.2.x.
>>
>> I think 2 feature releases means 3.x and 4.x here?
>
> At the moment when 4.0.0 is released, there won't be any new feature
> release in 3.x.
>
> Based on the 18months schedules we would have 1 LTS followed by 5
> non-LTS releases (without counting patch releases). There won't be any
> 3.x feature release after 3.5.
>
> Example using hypothetical dates:
> * Jan 2023 --- 3.0
> * Apr 2023 --- 3.1
> * Jul 2023 --- 3.2
> * Oct 2023 --- 3.3
> * Jan 2024 --- 3.4
> * Apr 2024 --- 3.5
> * Jul 2024 --- 4.0
> * Oct 2024 --- 4.1
> * ….
Schedules always slip. Would you say that if the 3.x feature releases take too long with these hypothetical dates that 3.5 would be dropped in order to release 4.0 on schedule?
ATB,
Dave
Re: [DISCUSS] PIP-175: Extend time based release process
Posted by Matteo Merli <ma...@gmail.com>.
On Tue, Jun 7, 2022 at 10:14 PM PengHui Li <pe...@apache.org> wrote:
>
> I'm not sure I fully understand the LTS release and feature release.
>
> > 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
>
> In this example, we can only introduce new features in 3.1 and 3.2,
> and 3.1.x and 3.2.x should be the patch release based on the feature
> release?
Exactly, that aspect won't be changed. I will clarify more in the document.
> We can have one patch release for a month.
>
> 3.0.x is the LTS release that will support at most three years.
> After we have 4.0 LTS release, we will still support 3.0.x TLS for at least
> 18 months.
> And 4.0 TLS will have all the new features from 3.x
Correct.
> > 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
>
> Does this mean we can introduce new features in 3.x even if we have 4.x?
> And how many patch releases for the feature releases we will support,
> such as 3.1.x, 3.2.x, 3.3.x, 4.1.x, 4.2.x.
>
> I think 2 feature releases means 3.x and 4.x here?
At the moment when 4.0.0 is released, there won't be any new feature
release in 3.x.
Based on the 18months schedules we would have 1 LTS followed by 5
non-LTS releases (without counting patch releases). There won't be any
3.x feature release after 3.5.
Example using hypothetical dates:
* Jan 2023 --- 3.0
* Apr 2023 --- 3.1
* Jul 2023 --- 3.2
* Oct 2023 --- 3.3
* Jan 2024 --- 3.4
* Apr 2024 --- 3.5
* Jul 2024 --- 4.0
* Oct 2024 --- 4.1
* ....
Re: [DISCUSS] PIP-175: Extend time based release process
Posted by PengHui Li <pe...@apache.org>.
I'm not sure I fully understand the LTS release and feature release.
> 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
In this example, we can only introduce new features in 3.1 and 3.2,
and 3.1.x and 3.2.x should be the patch release based on the feature
release?
We can have one patch release for a month.
3.0.x is the LTS release that will support at most three years.
After we have 4.0 LTS release, we will still support 3.0.x TLS for at least
18 months.
And 4.0 TLS will have all the new features from 3.x
> 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
Does this mean we can introduce new features in 3.x even if we have 4.x?
And how many patch releases for the feature releases we will support,
such as 3.1.x, 3.2.x, 3.3.x, 4.1.x, 4.2.x.
I think 2 feature releases means 3.x and 4.x here?
Thanks,
Penghui
On Wed, Jun 8, 2022 at 12:41 PM Michael Marshall <mm...@apache.org>
wrote:
> Thanks for putting together this PIP to continue this discussion,
> Matteo. This is an important one.
>
> I'll need time to think over your points before I respond, but I want
> to address two of them right away.
>
> > Actually, I was wrong. PIP-47 says the last 4 releases so 2.7 would be
> included.
> > The point though still remains in that there's nowhere in the website
> > where a user could check until when the 2.7 release is going to be
> > supported.
>
> We actually do have this documented on the website. I added this page
> in February:
>
> https://pulsar.apache.org/docs/next/security-policy-and-supported-versions#supported-versions
> .
>
> > we'd be releasing 2 LTSs super close between each other
> > and we'd have to support 1 release more for the time being.
>
> I agree with this reasoning. If 2.10 is LTS, and I think it should be,
> 2.11 shouldn't be LTS.
>
> Thanks,
> Michael
>
> On Tue, Jun 7, 2022 at 6:39 PM Matteo Merli <ma...@gmail.com>
> wrote:
> >
> > > > 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.
> > >
> > > Is 2.7 EOL? If so then we need to announce it explicitly.
> >
> > Actually, I was wrong. PIP-47 says the last 4 releases so 2.7 would be
> included.
> > The point though still remains in that there's nowhere in the website
> > where a user could check until when the 2.7 release is going to be
> > supported.
> >
> > > > We need to ensure that we have a date set in stone to deliver the
> > > > release to users.
> > >
> > > I would like the new plan to address the delays in cherry picking
> changes. These must never wait until a release is being made. We must keep
> these up to date. If someone marks a PR for an older release then they are
> volunteering to do the cherry pick within a few days. We need to be
> prepared for a 0-day security release.
> >
> > I agree that this is a problem, though I'd prefer to keep it in a
> > separate proposal, specifically targeted at the process for patch
> > releases, to avoid putting too many things into a single discussion.
> >
> > > > 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.
> > >
> > > From our existing release what is LTS?
> >
> > Good point, as we discussed earlier, 2.10 should be marked as LTS for
> > being the last Java 8 release. I'll update the text to reflect this.
> >
> > > Does this mean that you are proposing the current Master as
> release/3.0 or will it remain 2.11?
> >
> > I was actually not thinking of changing the denomination of 2.11. On
> > one hand, it could make sense for being the first Java 17 release, but
> > on the other, we'd be releasing 2 LTSs super close between each other
> > and we'd have to support 1 release more for the time being.
> >
> > I'd like to hear more opinions here :)
> >
> > > > 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
> > >
> > > Are those times since the initial release? It would be helpful to have
> a swim lane diagram.
> >
> > Yes, from the initial release (eg: 3.0.0) and yes we would have a
> > clear diagram on the website.
> >
> > > > 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
> > >
> > > Please note that in the event of a security release that PMC members
> will generally need to do these in secret.
> >
> > No changes about that. This is only to set the user expectation for
> > how long they can expect the security patches.
> >
> > It doesn't change a comma on the PMC process of discussing such
> > releases, nor it would prevent doing additional security releases
> > outside of the "guaranteed" window.
> >
> > > What is the plan for bug fix / security releases on say 3.0?
> >
> > Since 3.0 would be LTS, based on the above-proposed table: 2y for bug
> > fixes - 3y for security patches
>
Re: [DISCUSS] PIP-175: Extend time based release process
Posted by Michael Marshall <mm...@apache.org>.
Thanks for putting together this PIP to continue this discussion,
Matteo. This is an important one.
I'll need time to think over your points before I respond, but I want
to address two of them right away.
> Actually, I was wrong. PIP-47 says the last 4 releases so 2.7 would be included.
> The point though still remains in that there's nowhere in the website
> where a user could check until when the 2.7 release is going to be
> supported.
We actually do have this documented on the website. I added this page
in February:
https://pulsar.apache.org/docs/next/security-policy-and-supported-versions#supported-versions.
> we'd be releasing 2 LTSs super close between each other
> and we'd have to support 1 release more for the time being.
I agree with this reasoning. If 2.10 is LTS, and I think it should be,
2.11 shouldn't be LTS.
Thanks,
Michael
On Tue, Jun 7, 2022 at 6:39 PM Matteo Merli <ma...@gmail.com> wrote:
>
> > > 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.
> >
> > Is 2.7 EOL? If so then we need to announce it explicitly.
>
> Actually, I was wrong. PIP-47 says the last 4 releases so 2.7 would be included.
> The point though still remains in that there's nowhere in the website
> where a user could check until when the 2.7 release is going to be
> supported.
>
> > > We need to ensure that we have a date set in stone to deliver the
> > > release to users.
> >
> > I would like the new plan to address the delays in cherry picking changes. These must never wait until a release is being made. We must keep these up to date. If someone marks a PR for an older release then they are volunteering to do the cherry pick within a few days. We need to be prepared for a 0-day security release.
>
> I agree that this is a problem, though I'd prefer to keep it in a
> separate proposal, specifically targeted at the process for patch
> releases, to avoid putting too many things into a single discussion.
>
> > > 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.
> >
> > From our existing release what is LTS?
>
> Good point, as we discussed earlier, 2.10 should be marked as LTS for
> being the last Java 8 release. I'll update the text to reflect this.
>
> > Does this mean that you are proposing the current Master as release/3.0 or will it remain 2.11?
>
> I was actually not thinking of changing the denomination of 2.11. On
> one hand, it could make sense for being the first Java 17 release, but
> on the other, we'd be releasing 2 LTSs super close between each other
> and we'd have to support 1 release more for the time being.
>
> I'd like to hear more opinions here :)
>
> > > 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
> >
> > Are those times since the initial release? It would be helpful to have a swim lane diagram.
>
> Yes, from the initial release (eg: 3.0.0) and yes we would have a
> clear diagram on the website.
>
> > > 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
> >
> > Please note that in the event of a security release that PMC members will generally need to do these in secret.
>
> No changes about that. This is only to set the user expectation for
> how long they can expect the security patches.
>
> It doesn't change a comma on the PMC process of discussing such
> releases, nor it would prevent doing additional security releases
> outside of the "guaranteed" window.
>
> > What is the plan for bug fix / security releases on say 3.0?
>
> Since 3.0 would be LTS, based on the above-proposed table: 2y for bug
> fixes - 3y for security patches
Re: [DISCUSS] PIP-175: Extend time based release process
Posted by Matteo Merli <ma...@gmail.com>.
> > 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.
>
> Is 2.7 EOL? If so then we need to announce it explicitly.
Actually, I was wrong. PIP-47 says the last 4 releases so 2.7 would be included.
The point though still remains in that there's nowhere in the website
where a user could check until when the 2.7 release is going to be
supported.
> > We need to ensure that we have a date set in stone to deliver the
> > release to users.
>
> I would like the new plan to address the delays in cherry picking changes. These must never wait until a release is being made. We must keep these up to date. If someone marks a PR for an older release then they are volunteering to do the cherry pick within a few days. We need to be prepared for a 0-day security release.
I agree that this is a problem, though I'd prefer to keep it in a
separate proposal, specifically targeted at the process for patch
releases, to avoid putting too many things into a single discussion.
> > 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.
>
> From our existing release what is LTS?
Good point, as we discussed earlier, 2.10 should be marked as LTS for
being the last Java 8 release. I'll update the text to reflect this.
> Does this mean that you are proposing the current Master as release/3.0 or will it remain 2.11?
I was actually not thinking of changing the denomination of 2.11. On
one hand, it could make sense for being the first Java 17 release, but
on the other, we'd be releasing 2 LTSs super close between each other
and we'd have to support 1 release more for the time being.
I'd like to hear more opinions here :)
> > 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
>
> Are those times since the initial release? It would be helpful to have a swim lane diagram.
Yes, from the initial release (eg: 3.0.0) and yes we would have a
clear diagram on the website.
> > 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
>
> Please note that in the event of a security release that PMC members will generally need to do these in secret.
No changes about that. This is only to set the user expectation for
how long they can expect the security patches.
It doesn't change a comma on the PMC process of discussing such
releases, nor it would prevent doing additional security releases
outside of the "guaranteed" window.
> What is the plan for bug fix / security releases on say 3.0?
Since 3.0 would be LTS, based on the above-proposed table: 2y for bug
fixes - 3y for security patches
Re: [DISCUSS] PIP-175: Extend time based release process
Posted by Dave Fisher <wa...@apache.org>.
Hi -
Interesting, some responses inline.
> On Jun 7, 2022, at 3:25 PM, Matteo Merli <ma...@gmail.com> 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.
Is 2.7 EOL? If so then we need to announce it explicitly.
>
> 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.
I would like the new plan to address the delays in cherry picking changes. These must never wait until a release is being made. We must keep these up to date. If someone marks a PR for an older release then they are volunteering to do the cherry pick within a few days. We need to be prepared for a 0-day security release.
>
> ## 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.
From our existing release what is LTS?
Does this mean that you are proposing the current Master as release/3.0 or will it remain 2.11?
>
> #### 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
Are those times since the initial release? It would be helpful to have a swim lane diagram.
> 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
Please note that in the event of a security release that PMC members will generally need to do these in secret.
>
> 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.
What is the plan for bug fix / security releases on say 3.0?
Regards,
Dave
>
>
>
>
> --
> Matteo Merli
> <ma...@gmail.com>