LGTM +1 PIP-47 itself also has this scenario consideration. We can quickly iterate through small versions to quickly respond to problems that may occur in each major version, and we can submit patches for major versions at any time.
-- Thanks Xiaolong Ran Michael Marshall <mikemars...@gmail.com> 于2021年5月28日周五 上午5:49写道： > Hi Pulsar Community, > > > I would like to discuss defining and documenting a process for an official > Pulsar version EOL policy. This process will help users know when the > version they are running will no longer be supported with security patches. > > After the recent announcement of CVE-2021-22160, I looked on the official > pulsar website for a documented process describing which branches will > receive security patches when vulnerabilities are discovered. I could not > find a process on the website. I did find a policy for handling version EOL > described in PIP-47, though ( > > https://github.com/apache/pulsar/wiki/PIP-47%3A-Time-Based-Release-Plan#what-is-our-eol-policy > ). > Based on the policy, I would have expected a release of 2.6.4 with the > security patch for CVE-2021-22160, but that patch was not cherry-picked to > branch-2.6 until this week after the publication of the CVE, and we’re only > just now starting the process to release 2.6.4. > > I think it’s also relevant to consult the ASF guide for vulnerability > handling. The process is outlined here: > https://www.apache.org/security/committers.html. Regarding releasing > fixes, > it only mentions the following: > > > 15. The project team creates a release that includes the fix. > > > 16. The project team announces the vulnerability. The vulnerability > announcement should be sent after, or at the same time as, the release > announcement to the following destinations. > > Given the above information, I think it would be appropriate to have a > policy that ensures all active/supported branches receive security patches > before a CVE is announced. > > I propose we adopt a policy similar to Apache Spark’s policy, which is to > provide security fixes for feature branches for at least 18 months after > the initial minor version release: > https://spark.apache.org/versioning-policy.html. If we apply this policy > to > Pulsar, 2.6.x will receive security patches until December 2021 (2.6.0 was > released in June 2020). > > When I brought this up at the community meeting today, Matteo mentioned > supporting releases for a year. I am open to that time frame as well. My > main objective is to have a policy that is documented and easily discovered > by our users. > > I look forward to your thoughts and suggestions. > > Thanks, > > Michael Marshall >
