Re: Moving 3.5 to EOL
Regarding the suggestion: "Maybe we can also communicate that we’re going to officially EoL the least recent ZK version every 2 years." If you release new versions less frequently than that, the number of maintenance versions will go to 0 (though, in practice, you wouldn't EOL your current release). If you release more frequently, you'll be stuck maintaining an increasing number of versions. To keep the maintenance burden relatively consistent, I suggest tying your EOL schedule to your release schedule, so when you release a new version, you drop the oldest one. If you release every 2 years, then it works out the same. But if you release more or less often, your maintenance burden stays consistent. I would start by deciding the minimum number of concurrent versions you want to maintain. I suggest no more than 2, but ZK currently has 3, and is about to be 4 soon. If you're not marking specific versions as long-term stable, then the default would be to assume you're maintaining the most recent versions. Then, consider churn. If you release frequently, you may want to set a minimum age for maintenance, so users aren't forced to upgrade too often. So, if you start with 2 concurrent versions and you have a few versions released rapidly, you may temporarily need to support up to 3 or 4 releases until the oldest ones reach the minimum age, like 2 years for example, and are able to be EOL'd. Then, consider upgrade overlap. When you release, you could EOL the oldest version right away. But, it might be nicer to wait a few months, or maybe up to a year, before the oldest one is EOL'd. I previously mentioned Accumulo's "LTM" strategy. These are the core considerations we had in mind. So, for example, we support a minimum of 1 LTM version, with a 1 year overlap. We don't release frequently enough for the minimum age to be of concern. However, we did want to allow for intermediate feature preview releases that are immediately EOL as soon as a newer version is available. So, at any given time, we are maintaining between 1 and 2 LTM releases, and no more than 1 non-LTM release. We also use this to provide users with information about supported upgrade paths so users can upgrade from LTM to LTM, skipping over non-LTM releases, or they can stay on the latest (whether or not it is LTM). For ZooKeeper, I would suggest: * maintain at least 2 versions (currently 3.6 and 3.7) * maintain for at least 3 years before EOL On Fri, Feb 11, 2022 at 9:10 AM Andor Molnar wrote: > Thanks for the pointers. It was good to help refreshing my memory. > > We definitely missed the communication when stable and current links were > flipped from one version to another. Things will get more interesting when > Enrico finally releases 3.8.0. We’ll end up having 3 different “stable" > branches and 3.8 will become the “current”. > > What can we do with this? > > Announcing 3.5 EoL > ~~ > > This should have been done before flipping the stable pointer, but anyway, > here’re the points that we considered when doing the same for 3.4: > - Discussion happened in March/April 2020, EoL was announced for 1st of > June, 2020 (3 months ahead). > > - Define what EOL means - This is already discussed, text can be > copy-pasted from 3.4 EoL message, > > - Provide guidelines for upgrading paths, > > - State interoperability guarantees >- Previous version of ZooKeeper client is able to connect to server as > long > as there’s no new feature enforced on server side, >- Previous version of ZooKeeper server is able to accept connections > from > clients as long as they don’t want to use new features. > > - Curator already supports later versions - Is it true for 3.6, 3.7? > > It’s February now, so if we nail down the above points, I don’t see any > objections against announcing 3.5 EoL for 1st of June, 2022 (2 years after > 3.4 EoL, providing 4 months to upgrade). Maybe we can also communicate that > we’re going to officially EoL the least recent ZK version every 2 years. > > Andor > > > > > > On 2022. Feb 9., at 20:28, Patrick Hunt wrote: > > > > On Wed, Feb 9, 2022 at 3:07 AM Andor Molnar wrote: > > > >> Hi Pat, > >> > >> Yeah, I asked for a more specific suggestion from you. If we avoid using > >> the LTS in ZooKeeper releases and stay with the stable/latest labels, > how > >> would you label the current maintained versions? > >> > > > > Ah, ok. No worries Andor, I misunderstood. My 0.02: > > > > We have "stable" and "current" already identified. > > https://dlcdn.apache.org/zookeeper/ > > Stable was last updated in April of 2021. My recommendation is that we > > should change the process to notify EOL prior to updating e.g. "stable" > > reference. Stable is our indication w/o using the LTS label. As long as > we > > have a public policy & associated announcements, I think that's fine. > > > > I also bring your attention to this conversation thread from March 2020 > for > > the previous EOL'd (3.4) release line: > >
Re: Moving 3.5 to EOL
Thanks for the pointers. It was good to help refreshing my memory. We definitely missed the communication when stable and current links were flipped from one version to another. Things will get more interesting when Enrico finally releases 3.8.0. We’ll end up having 3 different “stable" branches and 3.8 will become the “current”. What can we do with this? Announcing 3.5 EoL ~~ This should have been done before flipping the stable pointer, but anyway, here’re the points that we considered when doing the same for 3.4: - Discussion happened in March/April 2020, EoL was announced for 1st of June, 2020 (3 months ahead). - Define what EOL means - This is already discussed, text can be copy-pasted from 3.4 EoL message, - Provide guidelines for upgrading paths, - State interoperability guarantees - Previous version of ZooKeeper client is able to connect to server as long as there’s no new feature enforced on server side, - Previous version of ZooKeeper server is able to accept connections from clients as long as they don’t want to use new features. - Curator already supports later versions - Is it true for 3.6, 3.7? It’s February now, so if we nail down the above points, I don’t see any objections against announcing 3.5 EoL for 1st of June, 2022 (2 years after 3.4 EoL, providing 4 months to upgrade). Maybe we can also communicate that we’re going to officially EoL the least recent ZK version every 2 years. Andor > On 2022. Feb 9., at 20:28, Patrick Hunt wrote: > > On Wed, Feb 9, 2022 at 3:07 AM Andor Molnar wrote: > >> Hi Pat, >> >> Yeah, I asked for a more specific suggestion from you. If we avoid using >> the LTS in ZooKeeper releases and stay with the stable/latest labels, how >> would you label the current maintained versions? >> > > Ah, ok. No worries Andor, I misunderstood. My 0.02: > > We have "stable" and "current" already identified. > https://dlcdn.apache.org/zookeeper/ > Stable was last updated in April of 2021. My recommendation is that we > should change the process to notify EOL prior to updating e.g. "stable" > reference. Stable is our indication w/o using the LTS label. As long as we > have a public policy & associated announcements, I think that's fine. > > I also bring your attention to this conversation thread from March 2020 for > the previous EOL'd (3.4) release line: > https://markmail.org/message/b2pqcztlb2ixoyjp > Some good ideas in there from many folks, I think we settled on a timeframe > we felt comfortable with, at least at the time. Unfortunately we did not > follow through with a plan for future releases. Perhaps we can do that now. > > Regards, > > Patrick > > >> >> Enrico is about to release 3.8.0 soon, so we’ll end up having four >> versions in maintenance. What should we do with it to reduce the >> maintenance cost? >> >> Andor >> >> >> >> >>> On 2022. Feb 4., at 17:58, Patrick Hunt wrote: >>> >>> On Fri, Feb 4, 2022 at 8:19 AM Andor Molnar wrote: >>> More specifically? >>> >>> Are you asking me? :-) "LTS" literally has a definition in wikipedia: >>> https://en.wikipedia.org/wiki/Long-term_support >>> >>> Stable 3.5, 3.6, 3.7, 3.8 and EoL 3.5 at the end of the year (1st of >> Jan, 2023)? Andor > On 2022. Feb 1., at 16:41, Patrick Hunt wrote: > > "LTS" typically has meaning for folks beyond just what the words say. >> JDK > LTS. Ubuntu LTS. etc... I think it would be less confusing to stay with the > stable/latest labels we have had in the past and plan ahead a bit in terms > of giving notice when releases will be removed from support. > > Patrick > > On Tue, Feb 1, 2022 at 3:12 AM Andor Molnar wrote: > >> Hi Andrew, >> >> I think that wasn’t a general plan from the community at that time, >> just >> my opinion based on how long 3.4 was the stable release of ZooKeeper >> (4 >> years). Since then the release schedule has become much faster and to >> be >> honest I’m not participating in it. >> >> As mentioned 3.6 and 3.7 releases are not much different. 3.6 is the >> “Facebook” version which is well tested and contains lots of patches that >> improves robustness. Both versions are good candidates for upgrade, so >> announcing 3.5 EoL (at least half year from now) is not necessarily >> bad. >> >> As an alternative, staying with the LT(S|M) / non-LT(S|M) terms, I >> think >> the following could also be considered for the community: >> >> Now: >> >> master >> -- >> 3.7 >> 3.6 >> 3.5 LTS >> -- >> 3.4 EoL >> >> Can become: >> >> master >> -- >> 3.8 LTS >> 3.7 >> 3.5 LTS >> -- >> 3.6 EoL >> 3.4 EoL >> >> In order to keep the number of maintained branches low. >> >> What do you think? >> >> Andor
[jira] [Created] (ZOOKEEPER-4469) Suppress OWASP false positives related to Netty TCNative
Enrico Olivelli created ZOOKEEPER-4469:
--
Summary: Suppress OWASP false positives related to Netty TCNative
Key: ZOOKEEPER-4469
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4469
Project: ZooKeeper
Issue Type: Task
Components: build
Reporter: Enrico Olivelli
Assignee: Enrico Olivelli
Fix For: 3.8.0, 3.7.1, 3.6.4
OWASP check is reporting this CVEs against netty-tcnative-2.0.48.Final
Those are not problems that affect ZooKeeper, we can exclude them
{code:java}
[ERROR] One or more dependencies were identified with vulnerabilities that have
a CVSS score greater than or equal to '0.0':
[ERROR]
[ERROR] netty-tcnative-2.0.48.Final.jar: CVE-2021-43797, CVE-2019-16869,
CVE-2015-2156, CVE-2021-37136, CVE-2014-3488, CVE-2021-37137, CVE-2019-20445,
CVE-2019-20444, CVE-2021-21295, CVE-2021-21409, CVE-2021-21290
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
