Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
Il Mer 8 Apr 2020, 12:34 Andor Molnar ha scritto:
> Hi,
>
> I’ve finished my quick testing on compatibility and all combinations are
> working fine in both ways: higher version clients are able to connect and
> run basic commands on older servers and vica versa.
>
> Tested latest released versions of 3.4, 3.5 and 3.6 branches with all
> possible combinations.
>
Good.
One day we will have automated testing of this stuff :)
> If there’s no more concerns or thoughts to share from the community, I’ll
> send the announcement this afternoon CEST.
>
+1
Enrico
> Thanks,
> Andor
>
>
>
>
> > On 2020. Apr 4., at 23:09, Patrick Hunt wrote:
> >
> > On Fri, Apr 3, 2020 at 10:59 PM Christopher wrote:
> >
> >> On Fri, Apr 3, 2020 at 12:57 PM Patrick Hunt wrote:
> >>>
> >>> On Thu, Apr 2, 2020 at 1:14 PM Christopher
> wrote:
> >>>
> On Thu, Apr 2, 2020 at 12:20 PM Patrick Hunt
> wrote:
> >
> > On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar
> >> wrote:
> >
> >> Alright. Not sure how to coordinate this properly, let’s try to
> >> discuss
> >> these 3 points individually.
> >>
> >> 1) EOL is 1st of June, 2020 which means from this day forward 3.4
> >> is
> ...
> >> - not supported by the community dev team,
> >> - not accepting patches, no future releases, no security fixes,
> >> - latest version is still accessible at download page for 1(?)
> >> year
> >>
> >>
> > Apache archival process is documented on this page:
> > https://www.apache.org/legal/release-policy.html#when-to-archive
> > we do get nudged on it every so often: e.g.
> > https://issues.apache.org/jira/browse/ZOOKEEPER-1752
>
> The archival process is regarding removal of old versions from the
> mirroring system. It does not apply to "current" releases ("current"
> being defined as still linked from the project's download page).
>
>
> >>> The text is pretty unequivocal and not what you are saying.
> >>>
> >>> "downloads.apache.org should contain *the latest release in each
> branch
> >>> that is currently under development*. When development ceases on a
> >> version
> >>> branch, releases of that branch should be removed from the project's
> >>> download directory."
> >>>
> >>> Meaning it should go to archive only once the branch is no longer under
> >>> active development, not that it would be "removed". The semantics btw
> >>> archive and remove are different. I don't think we should ever truly
> >>> "remove" anything once we've officially released it. eg. you can still
> >> find
> >>> 3.3 on the archive site if you want it.
> >>
> >> The portion you are quoting is from an FAQ, below the release policy,
> >> not the release policy itself. The actual policy doesn't address the
> >> archival *process*, only the requirement that releases be archived.
> >> The release policy is set by VP Legal, whereas the release and
> >> archival *processes* are managed by VP Infra. The FAQs have their
> >> shortcomings and could be improved (this isn't the first time these
> >> FAQs have caused confusion by seemingly conflicting with how INFRA
> >> operates the distribution channels).
> >>
> >> In order to be consistent with best practices for how the mirror
> >> system is intended to be used for release artifact distribution, I
> >> interpret "When development ceases" to refer to the entire development
> >> lifecycle, including release promotion via announcements and
> >> availability on the downloads page. Otherwise, you'd have to archive
> >> any "final release" of a branch immediately, and if you wanted to
> >> widely distribute the release by promoting it on the downloads page,
> >> you would have to link to the archives which is *BAD*. Projects
> >> should distribute releases via the mirroring system, not via the
> >> archives. Once they stop promoting the artifacts on their downloads
> >> page, the artifacts should be removed (archived) from
> >> SVN/dist.apache.org as the same time.
> >>
> >> If you're uncomfortable with interpreting "development" to include the
> >> release promotion period where they are linked on the downloads page,
> >> you could instead just choose to not "cease" development until you are
> >> ready to remove it from the downloads page. You could slow development
> >> down to the point where maybe you might still release critical
> >> security fixes, for example, but really nothing else. Development is
> >> still "active" and hasn't "ceased". But, what you should not do, is
> >> continue promoting the artifact on the downloads page with a link to
> >> the archives.
> >>
> >> If somebody from INFRA wants to contradict me on this... I'm happy to
> >> be corrected with more accurate information... but I'm 99% confident
> >> they don't want releases being promoted that cause users to pull more
> >> heavily on the archives servers, as that would be a costly drain on
> >> Foundation resources.
> >>
> >> All that said, the last 3.4
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
Hi,
I’ve finished my quick testing on compatibility and all combinations are
working fine in both ways: higher version clients are able to connect and run
basic commands on older servers and vica versa.
Tested latest released versions of 3.4, 3.5 and 3.6 branches with all possible
combinations.
If there’s no more concerns or thoughts to share from the community, I’ll send
the announcement this afternoon CEST.
Thanks,
Andor
> On 2020. Apr 4., at 23:09, Patrick Hunt wrote:
>
> On Fri, Apr 3, 2020 at 10:59 PM Christopher wrote:
>
>> On Fri, Apr 3, 2020 at 12:57 PM Patrick Hunt wrote:
>>>
>>> On Thu, Apr 2, 2020 at 1:14 PM Christopher wrote:
>>>
On Thu, Apr 2, 2020 at 12:20 PM Patrick Hunt wrote:
>
> On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar
>> wrote:
>
>> Alright. Not sure how to coordinate this properly, let’s try to
>> discuss
>> these 3 points individually.
>>
>> 1) EOL is 1st of June, 2020 which means from this day forward 3.4
>> is
...
>> - not supported by the community dev team,
>> - not accepting patches, no future releases, no security fixes,
>> - latest version is still accessible at download page for 1(?)
>> year
>>
>>
> Apache archival process is documented on this page:
> https://www.apache.org/legal/release-policy.html#when-to-archive
> we do get nudged on it every so often: e.g.
> https://issues.apache.org/jira/browse/ZOOKEEPER-1752
The archival process is regarding removal of old versions from the
mirroring system. It does not apply to "current" releases ("current"
being defined as still linked from the project's download page).
>>> The text is pretty unequivocal and not what you are saying.
>>>
>>> "downloads.apache.org should contain *the latest release in each branch
>>> that is currently under development*. When development ceases on a
>> version
>>> branch, releases of that branch should be removed from the project's
>>> download directory."
>>>
>>> Meaning it should go to archive only once the branch is no longer under
>>> active development, not that it would be "removed". The semantics btw
>>> archive and remove are different. I don't think we should ever truly
>>> "remove" anything once we've officially released it. eg. you can still
>> find
>>> 3.3 on the archive site if you want it.
>>
>> The portion you are quoting is from an FAQ, below the release policy,
>> not the release policy itself. The actual policy doesn't address the
>> archival *process*, only the requirement that releases be archived.
>> The release policy is set by VP Legal, whereas the release and
>> archival *processes* are managed by VP Infra. The FAQs have their
>> shortcomings and could be improved (this isn't the first time these
>> FAQs have caused confusion by seemingly conflicting with how INFRA
>> operates the distribution channels).
>>
>> In order to be consistent with best practices for how the mirror
>> system is intended to be used for release artifact distribution, I
>> interpret "When development ceases" to refer to the entire development
>> lifecycle, including release promotion via announcements and
>> availability on the downloads page. Otherwise, you'd have to archive
>> any "final release" of a branch immediately, and if you wanted to
>> widely distribute the release by promoting it on the downloads page,
>> you would have to link to the archives which is *BAD*. Projects
>> should distribute releases via the mirroring system, not via the
>> archives. Once they stop promoting the artifacts on their downloads
>> page, the artifacts should be removed (archived) from
>> SVN/dist.apache.org as the same time.
>>
>> If you're uncomfortable with interpreting "development" to include the
>> release promotion period where they are linked on the downloads page,
>> you could instead just choose to not "cease" development until you are
>> ready to remove it from the downloads page. You could slow development
>> down to the point where maybe you might still release critical
>> security fixes, for example, but really nothing else. Development is
>> still "active" and hasn't "ceased". But, what you should not do, is
>> continue promoting the artifact on the downloads page with a link to
>> the archives.
>>
>> If somebody from INFRA wants to contradict me on this... I'm happy to
>> be corrected with more accurate information... but I'm 99% confident
>> they don't want releases being promoted that cause users to pull more
>> heavily on the archives servers, as that would be a costly drain on
>> Foundation resources.
>>
>> All that said, the last 3.4 release has been promoted on the downloads
>> page for over a year now, which is probably long enough for a final
>> release, so it's probably easiest to just go ahead and remove it from
>> your downloads page (and from the mirrors, of course) sooner, rather
>> than wait until later.
>>
>
> For 3.4 example
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
On Fri, Apr 3, 2020 at 10:59 PM Christopher wrote:
> On Fri, Apr 3, 2020 at 12:57 PM Patrick Hunt wrote:
> >
> > On Thu, Apr 2, 2020 at 1:14 PM Christopher wrote:
> >
> > > On Thu, Apr 2, 2020 at 12:20 PM Patrick Hunt wrote:
> > > >
> > > > On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar
> wrote:
> > > >
> > > > > Alright. Not sure how to coordinate this properly, let’s try to
> discuss
> > > > > these 3 points individually.
> > > > >
> > > > > 1) EOL is 1st of June, 2020 which means from this day forward 3.4
> is
> > > ...
> > > > >- not supported by the community dev team,
> > > > >- not accepting patches, no future releases, no security fixes,
> > > > >- latest version is still accessible at download page for 1(?)
> year
> > > > >
> > > > >
> > > > Apache archival process is documented on this page:
> > > > https://www.apache.org/legal/release-policy.html#when-to-archive
> > > > we do get nudged on it every so often: e.g.
> > > > https://issues.apache.org/jira/browse/ZOOKEEPER-1752
> > >
> > > The archival process is regarding removal of old versions from the
> > > mirroring system. It does not apply to "current" releases ("current"
> > > being defined as still linked from the project's download page).
> > >
> > >
> > The text is pretty unequivocal and not what you are saying.
> >
> > "downloads.apache.org should contain *the latest release in each branch
> > that is currently under development*. When development ceases on a
> version
> > branch, releases of that branch should be removed from the project's
> > download directory."
> >
> > Meaning it should go to archive only once the branch is no longer under
> > active development, not that it would be "removed". The semantics btw
> > archive and remove are different. I don't think we should ever truly
> > "remove" anything once we've officially released it. eg. you can still
> find
> > 3.3 on the archive site if you want it.
>
> The portion you are quoting is from an FAQ, below the release policy,
> not the release policy itself. The actual policy doesn't address the
> archival *process*, only the requirement that releases be archived.
> The release policy is set by VP Legal, whereas the release and
> archival *processes* are managed by VP Infra. The FAQs have their
> shortcomings and could be improved (this isn't the first time these
> FAQs have caused confusion by seemingly conflicting with how INFRA
> operates the distribution channels).
>
> In order to be consistent with best practices for how the mirror
> system is intended to be used for release artifact distribution, I
> interpret "When development ceases" to refer to the entire development
> lifecycle, including release promotion via announcements and
> availability on the downloads page. Otherwise, you'd have to archive
> any "final release" of a branch immediately, and if you wanted to
> widely distribute the release by promoting it on the downloads page,
> you would have to link to the archives which is *BAD*. Projects
> should distribute releases via the mirroring system, not via the
> archives. Once they stop promoting the artifacts on their downloads
> page, the artifacts should be removed (archived) from
> SVN/dist.apache.org as the same time.
>
> If you're uncomfortable with interpreting "development" to include the
> release promotion period where they are linked on the downloads page,
> you could instead just choose to not "cease" development until you are
> ready to remove it from the downloads page. You could slow development
> down to the point where maybe you might still release critical
> security fixes, for example, but really nothing else. Development is
> still "active" and hasn't "ceased". But, what you should not do, is
> continue promoting the artifact on the downloads page with a link to
> the archives.
>
> If somebody from INFRA wants to contradict me on this... I'm happy to
> be corrected with more accurate information... but I'm 99% confident
> they don't want releases being promoted that cause users to pull more
> heavily on the archives servers, as that would be a costly drain on
> Foundation resources.
>
> All that said, the last 3.4 release has been promoted on the downloads
> page for over a year now, which is probably long enough for a final
> release, so it's probably easiest to just go ahead and remove it from
> your downloads page (and from the mirrors, of course) sooner, rather
> than wait until later.
>
For 3.4 example specifically I don't see how it could be considered "in
development" if we state that it's EOL as detailed by Andor above. That
seems to meet the criteria as I understand it. I agree that removing it
from the downloads page would be reasonable and consistent with that intent.
Patrick
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
On Fri, Apr 3, 2020 at 12:57 PM Patrick Hunt wrote:
>
> On Thu, Apr 2, 2020 at 1:14 PM Christopher wrote:
>
> > On Thu, Apr 2, 2020 at 12:20 PM Patrick Hunt wrote:
> > >
> > > On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar wrote:
> > >
> > > > Alright. Not sure how to coordinate this properly, let’s try to discuss
> > > > these 3 points individually.
> > > >
> > > > 1) EOL is 1st of June, 2020 which means from this day forward 3.4 is
> > ...
> > > >- not supported by the community dev team,
> > > >- not accepting patches, no future releases, no security fixes,
> > > >- latest version is still accessible at download page for 1(?) year
> > > >
> > > >
> > > Apache archival process is documented on this page:
> > > https://www.apache.org/legal/release-policy.html#when-to-archive
> > > we do get nudged on it every so often: e.g.
> > > https://issues.apache.org/jira/browse/ZOOKEEPER-1752
> >
> > The archival process is regarding removal of old versions from the
> > mirroring system. It does not apply to "current" releases ("current"
> > being defined as still linked from the project's download page).
> >
> >
> The text is pretty unequivocal and not what you are saying.
>
> "downloads.apache.org should contain *the latest release in each branch
> that is currently under development*. When development ceases on a version
> branch, releases of that branch should be removed from the project's
> download directory."
>
> Meaning it should go to archive only once the branch is no longer under
> active development, not that it would be "removed". The semantics btw
> archive and remove are different. I don't think we should ever truly
> "remove" anything once we've officially released it. eg. you can still find
> 3.3 on the archive site if you want it.
The portion you are quoting is from an FAQ, below the release policy,
not the release policy itself. The actual policy doesn't address the
archival *process*, only the requirement that releases be archived.
The release policy is set by VP Legal, whereas the release and
archival *processes* are managed by VP Infra. The FAQs have their
shortcomings and could be improved (this isn't the first time these
FAQs have caused confusion by seemingly conflicting with how INFRA
operates the distribution channels).
In order to be consistent with best practices for how the mirror
system is intended to be used for release artifact distribution, I
interpret "When development ceases" to refer to the entire development
lifecycle, including release promotion via announcements and
availability on the downloads page. Otherwise, you'd have to archive
any "final release" of a branch immediately, and if you wanted to
widely distribute the release by promoting it on the downloads page,
you would have to link to the archives which is *BAD*. Projects
should distribute releases via the mirroring system, not via the
archives. Once they stop promoting the artifacts on their downloads
page, the artifacts should be removed (archived) from
SVN/dist.apache.org as the same time.
If you're uncomfortable with interpreting "development" to include the
release promotion period where they are linked on the downloads page,
you could instead just choose to not "cease" development until you are
ready to remove it from the downloads page. You could slow development
down to the point where maybe you might still release critical
security fixes, for example, but really nothing else. Development is
still "active" and hasn't "ceased". But, what you should not do, is
continue promoting the artifact on the downloads page with a link to
the archives.
If somebody from INFRA wants to contradict me on this... I'm happy to
be corrected with more accurate information... but I'm 99% confident
they don't want releases being promoted that cause users to pull more
heavily on the archives servers, as that would be a costly drain on
Foundation resources.
All that said, the last 3.4 release has been promoted on the downloads
page for over a year now, which is probably long enough for a final
release, so it's probably easiest to just go ahead and remove it from
your downloads page (and from the mirrors, of course) sooner, rather
than wait until later.
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
On Thu, Apr 2, 2020 at 1:14 PM Christopher wrote:
> On Thu, Apr 2, 2020 at 12:20 PM Patrick Hunt wrote:
> >
> > On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar wrote:
> >
> > > Alright. Not sure how to coordinate this properly, let’s try to discuss
> > > these 3 points individually.
> > >
> > > 1) EOL is 1st of June, 2020 which means from this day forward 3.4 is
> ...
> > >- not supported by the community dev team,
> > >- not accepting patches, no future releases, no security fixes,
> > >- latest version is still accessible at download page for 1(?) year
> > >
> > >
> > Apache archival process is documented on this page:
> > https://www.apache.org/legal/release-policy.html#when-to-archive
> > we do get nudged on it every so often: e.g.
> > https://issues.apache.org/jira/browse/ZOOKEEPER-1752
>
> The archival process is regarding removal of old versions from the
> mirroring system. It does not apply to "current" releases ("current"
> being defined as still linked from the project's download page).
>
>
The text is pretty unequivocal and not what you are saying.
"downloads.apache.org should contain *the latest release in each branch
that is currently under development*. When development ceases on a version
branch, releases of that branch should be removed from the project's
download directory."
Meaning it should go to archive only once the branch is no longer under
active development, not that it would be "removed". The semantics btw
archive and remove are different. I don't think we should ever truly
"remove" anything once we've officially released it. eg. you can still find
3.3 on the archive site if you want it.
Patrick
> The question here is regarding the timing for removal from the
> project's download page. I suggest event-based, rather than
> time-based. Since ZK seems to be maintaining 3 release lines
> concurrently, you could remove 3.4 when 3.7 is released, unless
> there's a good reason to drop it sooner (to reduce the number of
> concurrent releases supported to 2, for example).
>
> >
> >
> > > 2) Supported upgrade path is: latest 3.4 -> latest 3.5 -> latest 3.6
> > >
> > > 3) 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.
> > >
> > >
> > I believe 2/3 are consistent with "Backward Compatibility" here?
> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/ReleaseManagement
> >
> > Patrick
> >
> >
> > > Thoughts?
> > >
> > > Andor
> > >
> > >
> > >
> > >
> > > > On 2020. Apr 2., at 6:30, Michael Han wrote:
> > > >
> > > > +1.
> > > >
> > > > For EOL policy statement, just to throw something out here that i can
> > > think
> > > > of:
> > > >
> > > > * Define what EOL means (such as: not supported by community dev team
> > > > anymore, no future 3.4 releases .. still accessible at download page
> for
> > > X
> > > > years..) and a date of EOL.
> > > >
> > > > * Provide guidelines for upgrading paths to 3.5 / 3.6.
> > > >
> > > > * State interoperability guarantees another post pointed out
> previously ^
> > > >
> > > > On Wed, Apr 1, 2020 at 2:04 AM Andor Molnar
> wrote:
> > > >
> > > >> Hi folks,
> > > >>
> > > >> Based on Enrico’s latest post about a 3.4 client problem I’d like to
> > > push
> > > >> this initiative.
> > > >> Asking more senior members of the community what communicated
> policy is
> > > >> needed exactly to say 3.4 is EoL?
> > > >>
> > > >> In terms of timing I’d like Patrick’s suggestion about 1st of June,
> > > 2020.
> > > >>
> > > >> Any objections?
> > > >>
> > > >> Andor
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>> On 2020. Mar 4., at 18:45, Michael K. Edwards <
> m.k.edwa...@gmail.com>
> > > >> wrote:
> > > >>>
> > > >>> I think it would be useful for an EOL statement about 3.4.x to
> include
> > > a
> > > >>> policy on interoperability of newer ZooKeeper servers with 3.4.x
> client
> > > >>> code. Stacks that build on top of Kafka and Hadoop (I'm looking at
> > > you,
> > > >>> Spark) often wind up having an indirect dependency on a comically
> stale
> > > >>> ZooKeeper library. Even if this library isn't really exercised by
> the
> > > >>> client side of the stack, it's there in the mountain of jars; and
> when
> > > >>> application code also wants to use ZooKeeper more directly, using a
> > > newer
> > > >>> client library can get kind of messy. The approach I've taken has
> been
> > > >> to
> > > >>> rebuild large swathes of the stack around a consistent, recent
> > > ZooKeeper
> > > >>> build; but I think it would be relevant to a lot of people to know
> > > >> whether,
> > > >>> say, a 3.4.14 client will work reliably with a 3.6.x quorum.
> > > >>>
> > > >>> On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli <
> eolive...@gmail.com>
> > > >> wrote:
> > > >>>
> > > Il
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
I think maintaining and storing releases are two different things. We don’t
want to maintain 3 release lines that’s why we want to announce 3.4 EoL. Apache
asked us to host only the latest releases on ‘downloads’ server and move
everything else to ‘archive’. I don’t bother making them available for eternity
if Apache is happy with that. e.g. I’m still able to download 3.3.x versions
from the archive.
In terms of testing I’ll do some quick smoke tests with different client-server
combination before making the announcement. Bear with me.
Please keep share your thoughts until that.
Andor
> On 2020. Apr 2., at 22:14, Christopher wrote:
>
> On Thu, Apr 2, 2020 at 12:20 PM Patrick Hunt wrote:
>>
>> On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar wrote:
>>
>>> Alright. Not sure how to coordinate this properly, let’s try to discuss
>>> these 3 points individually.
>>>
>>> 1) EOL is 1st of June, 2020 which means from this day forward 3.4 is ...
>>> - not supported by the community dev team,
>>> - not accepting patches, no future releases, no security fixes,
>>> - latest version is still accessible at download page for 1(?) year
>>>
>>>
>> Apache archival process is documented on this page:
>> https://www.apache.org/legal/release-policy.html#when-to-archive
>> we do get nudged on it every so often: e.g.
>> https://issues.apache.org/jira/browse/ZOOKEEPER-1752
>
> The archival process is regarding removal of old versions from the
> mirroring system. It does not apply to "current" releases ("current"
> being defined as still linked from the project's download page).
>
> The question here is regarding the timing for removal from the
> project's download page. I suggest event-based, rather than
> time-based. Since ZK seems to be maintaining 3 release lines
> concurrently, you could remove 3.4 when 3.7 is released, unless
> there's a good reason to drop it sooner (to reduce the number of
> concurrent releases supported to 2, for example).
>
>>
>>
>>> 2) Supported upgrade path is: latest 3.4 -> latest 3.5 -> latest 3.6
>>>
>>> 3) 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.
>>>
>>>
>> I believe 2/3 are consistent with "Backward Compatibility" here?
>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/ReleaseManagement
>>
>> Patrick
>>
>>
>>> Thoughts?
>>>
>>> Andor
>>>
>>>
>>>
>>>
On 2020. Apr 2., at 6:30, Michael Han wrote:
+1.
For EOL policy statement, just to throw something out here that i can
>>> think
of:
* Define what EOL means (such as: not supported by community dev team
anymore, no future 3.4 releases .. still accessible at download page for
>>> X
years..) and a date of EOL.
* Provide guidelines for upgrading paths to 3.5 / 3.6.
* State interoperability guarantees another post pointed out previously ^
On Wed, Apr 1, 2020 at 2:04 AM Andor Molnar wrote:
> Hi folks,
>
> Based on Enrico’s latest post about a 3.4 client problem I’d like to
>>> push
> this initiative.
> Asking more senior members of the community what communicated policy is
> needed exactly to say 3.4 is EoL?
>
> In terms of timing I’d like Patrick’s suggestion about 1st of June,
>>> 2020.
>
> Any objections?
>
> Andor
>
>
>
>
>> On 2020. Mar 4., at 18:45, Michael K. Edwards
> wrote:
>>
>> I think it would be useful for an EOL statement about 3.4.x to include
>>> a
>> policy on interoperability of newer ZooKeeper servers with 3.4.x client
>> code. Stacks that build on top of Kafka and Hadoop (I'm looking at
>>> you,
>> Spark) often wind up having an indirect dependency on a comically stale
>> ZooKeeper library. Even if this library isn't really exercised by the
>> client side of the stack, it's there in the mountain of jars; and when
>> application code also wants to use ZooKeeper more directly, using a
>>> newer
>> client library can get kind of messy. The approach I've taken has been
> to
>> rebuild large swathes of the stack around a consistent, recent
>>> ZooKeeper
>> build; but I think it would be relevant to a lot of people to know
> whether,
>> say, a 3.4.14 client will work reliably with a 3.6.x quorum.
>>
>> On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli
> wrote:
>>
>>> Il giorno mer 4 mar 2020 alle ore 17:23 Patrick Hunt
>>> ha scritto:
It seems like we should have a stated/communicated policy around
> release
lifecycles before sending an EOL message. That way folks have some
> runway
to plan for the event, both near term (3.4) as well as
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
Well, for a long time we only had 1 line maintained, 3.4 basically. It is
just right now we have 3 lines, which is I think one too many. (Plus we
also have master to maintain additional to the active release lines, that's
4 active branches. Well, more or less, 3.4 is pretty inactive already).
I pretty much agree with Andor's points. My only comment is what testing do
we do to achieve number 3? (different version of client-server
connectability)
- Norbert
On Thu, Apr 2, 2020 at 10:14 PM Christopher wrote:
> On Thu, Apr 2, 2020 at 12:20 PM Patrick Hunt wrote:
> >
> > On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar wrote:
> >
> > > Alright. Not sure how to coordinate this properly, let’s try to discuss
> > > these 3 points individually.
> > >
> > > 1) EOL is 1st of June, 2020 which means from this day forward 3.4 is
> ...
> > >- not supported by the community dev team,
> > >- not accepting patches, no future releases, no security fixes,
> > >- latest version is still accessible at download page for 1(?) year
> > >
> > >
> > Apache archival process is documented on this page:
> > https://www.apache.org/legal/release-policy.html#when-to-archive
> > we do get nudged on it every so often: e.g.
> > https://issues.apache.org/jira/browse/ZOOKEEPER-1752
>
> The archival process is regarding removal of old versions from the
> mirroring system. It does not apply to "current" releases ("current"
> being defined as still linked from the project's download page).
>
> The question here is regarding the timing for removal from the
> project's download page. I suggest event-based, rather than
> time-based. Since ZK seems to be maintaining 3 release lines
> concurrently, you could remove 3.4 when 3.7 is released, unless
> there's a good reason to drop it sooner (to reduce the number of
> concurrent releases supported to 2, for example).
>
> >
> >
> > > 2) Supported upgrade path is: latest 3.4 -> latest 3.5 -> latest 3.6
> > >
> > > 3) 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.
> > >
> > >
> > I believe 2/3 are consistent with "Backward Compatibility" here?
> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/ReleaseManagement
> >
> > Patrick
> >
> >
> > > Thoughts?
> > >
> > > Andor
> > >
> > >
> > >
> > >
> > > > On 2020. Apr 2., at 6:30, Michael Han wrote:
> > > >
> > > > +1.
> > > >
> > > > For EOL policy statement, just to throw something out here that i can
> > > think
> > > > of:
> > > >
> > > > * Define what EOL means (such as: not supported by community dev team
> > > > anymore, no future 3.4 releases .. still accessible at download page
> for
> > > X
> > > > years..) and a date of EOL.
> > > >
> > > > * Provide guidelines for upgrading paths to 3.5 / 3.6.
> > > >
> > > > * State interoperability guarantees another post pointed out
> previously ^
> > > >
> > > > On Wed, Apr 1, 2020 at 2:04 AM Andor Molnar
> wrote:
> > > >
> > > >> Hi folks,
> > > >>
> > > >> Based on Enrico’s latest post about a 3.4 client problem I’d like to
> > > push
> > > >> this initiative.
> > > >> Asking more senior members of the community what communicated
> policy is
> > > >> needed exactly to say 3.4 is EoL?
> > > >>
> > > >> In terms of timing I’d like Patrick’s suggestion about 1st of June,
> > > 2020.
> > > >>
> > > >> Any objections?
> > > >>
> > > >> Andor
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>> On 2020. Mar 4., at 18:45, Michael K. Edwards <
> m.k.edwa...@gmail.com>
> > > >> wrote:
> > > >>>
> > > >>> I think it would be useful for an EOL statement about 3.4.x to
> include
> > > a
> > > >>> policy on interoperability of newer ZooKeeper servers with 3.4.x
> client
> > > >>> code. Stacks that build on top of Kafka and Hadoop (I'm looking at
> > > you,
> > > >>> Spark) often wind up having an indirect dependency on a comically
> stale
> > > >>> ZooKeeper library. Even if this library isn't really exercised by
> the
> > > >>> client side of the stack, it's there in the mountain of jars; and
> when
> > > >>> application code also wants to use ZooKeeper more directly, using a
> > > newer
> > > >>> client library can get kind of messy. The approach I've taken has
> been
> > > >> to
> > > >>> rebuild large swathes of the stack around a consistent, recent
> > > ZooKeeper
> > > >>> build; but I think it would be relevant to a lot of people to know
> > > >> whether,
> > > >>> say, a 3.4.14 client will work reliably with a 3.6.x quorum.
> > > >>>
> > > >>> On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli <
> eolive...@gmail.com>
> > > >> wrote:
> > > >>>
> > > Il giorno mer 4 mar 2020 alle ore 17:23 Patrick Hunt
> > > ha scritto:
> > > >
> > > > It seems like we should have a stated/communicated policy around
> > > >> release
>
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
On Thu, Apr 2, 2020 at 12:20 PM Patrick Hunt wrote:
>
> On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar wrote:
>
> > Alright. Not sure how to coordinate this properly, let’s try to discuss
> > these 3 points individually.
> >
> > 1) EOL is 1st of June, 2020 which means from this day forward 3.4 is ...
> >- not supported by the community dev team,
> >- not accepting patches, no future releases, no security fixes,
> >- latest version is still accessible at download page for 1(?) year
> >
> >
> Apache archival process is documented on this page:
> https://www.apache.org/legal/release-policy.html#when-to-archive
> we do get nudged on it every so often: e.g.
> https://issues.apache.org/jira/browse/ZOOKEEPER-1752
The archival process is regarding removal of old versions from the
mirroring system. It does not apply to "current" releases ("current"
being defined as still linked from the project's download page).
The question here is regarding the timing for removal from the
project's download page. I suggest event-based, rather than
time-based. Since ZK seems to be maintaining 3 release lines
concurrently, you could remove 3.4 when 3.7 is released, unless
there's a good reason to drop it sooner (to reduce the number of
concurrent releases supported to 2, for example).
>
>
> > 2) Supported upgrade path is: latest 3.4 -> latest 3.5 -> latest 3.6
> >
> > 3) 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.
> >
> >
> I believe 2/3 are consistent with "Backward Compatibility" here?
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/ReleaseManagement
>
> Patrick
>
>
> > Thoughts?
> >
> > Andor
> >
> >
> >
> >
> > > On 2020. Apr 2., at 6:30, Michael Han wrote:
> > >
> > > +1.
> > >
> > > For EOL policy statement, just to throw something out here that i can
> > think
> > > of:
> > >
> > > * Define what EOL means (such as: not supported by community dev team
> > > anymore, no future 3.4 releases .. still accessible at download page for
> > X
> > > years..) and a date of EOL.
> > >
> > > * Provide guidelines for upgrading paths to 3.5 / 3.6.
> > >
> > > * State interoperability guarantees another post pointed out previously ^
> > >
> > > On Wed, Apr 1, 2020 at 2:04 AM Andor Molnar wrote:
> > >
> > >> Hi folks,
> > >>
> > >> Based on Enrico’s latest post about a 3.4 client problem I’d like to
> > push
> > >> this initiative.
> > >> Asking more senior members of the community what communicated policy is
> > >> needed exactly to say 3.4 is EoL?
> > >>
> > >> In terms of timing I’d like Patrick’s suggestion about 1st of June,
> > 2020.
> > >>
> > >> Any objections?
> > >>
> > >> Andor
> > >>
> > >>
> > >>
> > >>
> > >>> On 2020. Mar 4., at 18:45, Michael K. Edwards
> > >> wrote:
> > >>>
> > >>> I think it would be useful for an EOL statement about 3.4.x to include
> > a
> > >>> policy on interoperability of newer ZooKeeper servers with 3.4.x client
> > >>> code. Stacks that build on top of Kafka and Hadoop (I'm looking at
> > you,
> > >>> Spark) often wind up having an indirect dependency on a comically stale
> > >>> ZooKeeper library. Even if this library isn't really exercised by the
> > >>> client side of the stack, it's there in the mountain of jars; and when
> > >>> application code also wants to use ZooKeeper more directly, using a
> > newer
> > >>> client library can get kind of messy. The approach I've taken has been
> > >> to
> > >>> rebuild large swathes of the stack around a consistent, recent
> > ZooKeeper
> > >>> build; but I think it would be relevant to a lot of people to know
> > >> whether,
> > >>> say, a 3.4.14 client will work reliably with a 3.6.x quorum.
> > >>>
> > >>> On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli
> > >> wrote:
> > >>>
> > Il giorno mer 4 mar 2020 alle ore 17:23 Patrick Hunt
> > ha scritto:
> > >
> > > It seems like we should have a stated/communicated policy around
> > >> release
> > > lifecycles before sending an EOL message. That way folks have some
> > >> runway
> > > to plan for the event, both near term (3.4) as well as long term.
> >
> > Shall we set a deadline ?
> > Something like "3.4 will be EOL by the end of 2020" ?
> > At this point we are only "discussing" about sending 3.4 to EOL, no
> > decision has been made yet
> >
> >
> > Enrico
> >
> >
> > >
> > > Patrick
> > >
> > > On Wed, Mar 4, 2020 at 5:16 AM Szalay-Bekő Máté <
> > szalay.beko.m...@gmail.com>
> > > wrote:
> > >
> > >> Also a minor thing to consider: we wanted to ask the HBase community
> > >> to
> > >> upgrade to ZooKeeper 3.5 before, and the conclusion there was that
> > >> they
> > >> will do so only when the EOL will
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar wrote: > Alright. Not sure how to coordinate this properly, let’s try to discuss > these 3 points individually. > > 1) EOL is 1st of June, 2020 which means from this day forward 3.4 is ... >- not supported by the community dev team, >- not accepting patches, no future releases, no security fixes, >- latest version is still accessible at download page for 1(?) year > > Apache archival process is documented on this page: https://www.apache.org/legal/release-policy.html#when-to-archive we do get nudged on it every so often: e.g. https://issues.apache.org/jira/browse/ZOOKEEPER-1752 > 2) Supported upgrade path is: latest 3.4 -> latest 3.5 -> latest 3.6 > > 3) 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. > > I believe 2/3 are consistent with "Backward Compatibility" here? https://cwiki.apache.org/confluence/display/ZOOKEEPER/ReleaseManagement Patrick > Thoughts? > > Andor > > > > > > On 2020. Apr 2., at 6:30, Michael Han wrote: > > > > +1. > > > > For EOL policy statement, just to throw something out here that i can > think > > of: > > > > * Define what EOL means (such as: not supported by community dev team > > anymore, no future 3.4 releases .. still accessible at download page for > X > > years..) and a date of EOL. > > > > * Provide guidelines for upgrading paths to 3.5 / 3.6. > > > > * State interoperability guarantees another post pointed out previously ^ > > > > On Wed, Apr 1, 2020 at 2:04 AM Andor Molnar wrote: > > > >> Hi folks, > >> > >> Based on Enrico’s latest post about a 3.4 client problem I’d like to > push > >> this initiative. > >> Asking more senior members of the community what communicated policy is > >> needed exactly to say 3.4 is EoL? > >> > >> In terms of timing I’d like Patrick’s suggestion about 1st of June, > 2020. > >> > >> Any objections? > >> > >> Andor > >> > >> > >> > >> > >>> On 2020. Mar 4., at 18:45, Michael K. Edwards > >> wrote: > >>> > >>> I think it would be useful for an EOL statement about 3.4.x to include > a > >>> policy on interoperability of newer ZooKeeper servers with 3.4.x client > >>> code. Stacks that build on top of Kafka and Hadoop (I'm looking at > you, > >>> Spark) often wind up having an indirect dependency on a comically stale > >>> ZooKeeper library. Even if this library isn't really exercised by the > >>> client side of the stack, it's there in the mountain of jars; and when > >>> application code also wants to use ZooKeeper more directly, using a > newer > >>> client library can get kind of messy. The approach I've taken has been > >> to > >>> rebuild large swathes of the stack around a consistent, recent > ZooKeeper > >>> build; but I think it would be relevant to a lot of people to know > >> whether, > >>> say, a 3.4.14 client will work reliably with a 3.6.x quorum. > >>> > >>> On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli > >> wrote: > >>> > Il giorno mer 4 mar 2020 alle ore 17:23 Patrick Hunt > ha scritto: > > > > It seems like we should have a stated/communicated policy around > >> release > > lifecycles before sending an EOL message. That way folks have some > >> runway > > to plan for the event, both near term (3.4) as well as long term. > > Shall we set a deadline ? > Something like "3.4 will be EOL by the end of 2020" ? > At this point we are only "discussing" about sending 3.4 to EOL, no > decision has been made yet > > > Enrico > > > > > > Patrick > > > > On Wed, Mar 4, 2020 at 5:16 AM Szalay-Bekő Máté < > szalay.beko.m...@gmail.com> > > wrote: > > > >> Also a minor thing to consider: we wanted to ask the HBase community > >> to > >> upgrade to ZooKeeper 3.5 before, and the conclusion there was that > >> they > >> will do so only when the EOL will be at least scheduled / announced > on > the > >> ZooKeeper 3.4 versions. Maybe there are other ZooKeeper users as > well > who > >> will not upgrade until they get 'an official' statement about the > 3.4 > >> versions. > >> > >> On Wed, Mar 4, 2020 at 1:44 PM Jordan Zimmerman < > >> jor...@jordanzimmerman.com> > >> wrote: > >> > >>> I'm +1 on this. We're planning to drop support for 3.4.x in the > next > >>> release of Apache Curator, FYI. > >>> > >>> -Jordan > >>> > On Mar 4, 2020, at 7:36 AM, Enrico Olivelli > >> wrote: > > Hi, > we are releasing 3.6.0 (I am waiting for mirrors to sync before > updating the website). > > In my opinion it is time to officially send 3.4 branch to EOL > status, > >>> that is: > - we
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
Alright. Not sure how to coordinate this properly, let’s try to discuss these 3 points individually. 1) EOL is 1st of June, 2020 which means from this day forward 3.4 is ... - not supported by the community dev team, - not accepting patches, no future releases, no security fixes, - latest version is still accessible at download page for 1(?) year 2) Supported upgrade path is: latest 3.4 -> latest 3.5 -> latest 3.6 3) 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. Thoughts? Andor > On 2020. Apr 2., at 6:30, Michael Han wrote: > > +1. > > For EOL policy statement, just to throw something out here that i can think > of: > > * Define what EOL means (such as: not supported by community dev team > anymore, no future 3.4 releases .. still accessible at download page for X > years..) and a date of EOL. > > * Provide guidelines for upgrading paths to 3.5 / 3.6. > > * State interoperability guarantees another post pointed out previously ^ > > On Wed, Apr 1, 2020 at 2:04 AM Andor Molnar wrote: > >> Hi folks, >> >> Based on Enrico’s latest post about a 3.4 client problem I’d like to push >> this initiative. >> Asking more senior members of the community what communicated policy is >> needed exactly to say 3.4 is EoL? >> >> In terms of timing I’d like Patrick’s suggestion about 1st of June, 2020. >> >> Any objections? >> >> Andor >> >> >> >> >>> On 2020. Mar 4., at 18:45, Michael K. Edwards >> wrote: >>> >>> I think it would be useful for an EOL statement about 3.4.x to include a >>> policy on interoperability of newer ZooKeeper servers with 3.4.x client >>> code. Stacks that build on top of Kafka and Hadoop (I'm looking at you, >>> Spark) often wind up having an indirect dependency on a comically stale >>> ZooKeeper library. Even if this library isn't really exercised by the >>> client side of the stack, it's there in the mountain of jars; and when >>> application code also wants to use ZooKeeper more directly, using a newer >>> client library can get kind of messy. The approach I've taken has been >> to >>> rebuild large swathes of the stack around a consistent, recent ZooKeeper >>> build; but I think it would be relevant to a lot of people to know >> whether, >>> say, a 3.4.14 client will work reliably with a 3.6.x quorum. >>> >>> On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli >> wrote: >>> Il giorno mer 4 mar 2020 alle ore 17:23 Patrick Hunt ha scritto: > > It seems like we should have a stated/communicated policy around >> release > lifecycles before sending an EOL message. That way folks have some >> runway > to plan for the event, both near term (3.4) as well as long term. Shall we set a deadline ? Something like "3.4 will be EOL by the end of 2020" ? At this point we are only "discussing" about sending 3.4 to EOL, no decision has been made yet Enrico > > Patrick > > On Wed, Mar 4, 2020 at 5:16 AM Szalay-Bekő Máté < szalay.beko.m...@gmail.com> > wrote: > >> Also a minor thing to consider: we wanted to ask the HBase community >> to >> upgrade to ZooKeeper 3.5 before, and the conclusion there was that >> they >> will do so only when the EOL will be at least scheduled / announced on the >> ZooKeeper 3.4 versions. Maybe there are other ZooKeeper users as well who >> will not upgrade until they get 'an official' statement about the 3.4 >> versions. >> >> On Wed, Mar 4, 2020 at 1:44 PM Jordan Zimmerman < >> jor...@jordanzimmerman.com> >> wrote: >> >>> I'm +1 on this. We're planning to drop support for 3.4.x in the next >>> release of Apache Curator, FYI. >>> >>> -Jordan >>> On Mar 4, 2020, at 7:36 AM, Enrico Olivelli >> wrote: Hi, we are releasing 3.6.0 (I am waiting for mirrors to sync before updating the website). In my opinion it is time to officially send 3.4 branch to EOL status, >>> that is: - we are not expecting new releases - drop 3.4 from download area (it will stay on archives as usual) - strongly encourage people to update to 3.5/3.6 3.4 is far away from master branch and even from 3.6. There is a clean upgrade path from 3.4.LATEST to 3.5.7 and to 3.6 so users are able to upgrade. I am not sure we need a VOTE, if we simply agree I can drop 3.4 from the "dist" are as long as I push the new website. Best regards Enrico >>> >>> >> >> >>
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
+1 FYI - the next release of Curator will drop 3.4.x support. -Jordan > On Apr 1, 2020, at 11:30 PM, Michael Han wrote: > > +1. > > For EOL policy statement, just to throw something out here that i can think > of: > > * Define what EOL means (such as: not supported by community dev team > anymore, no future 3.4 releases .. still accessible at download page for X > years..) and a date of EOL. > > * Provide guidelines for upgrading paths to 3.5 / 3.6. > > * State interoperability guarantees another post pointed out previously ^ > > On Wed, Apr 1, 2020 at 2:04 AM Andor Molnar wrote: > >> Hi folks, >> >> Based on Enrico’s latest post about a 3.4 client problem I’d like to push >> this initiative. >> Asking more senior members of the community what communicated policy is >> needed exactly to say 3.4 is EoL? >> >> In terms of timing I’d like Patrick’s suggestion about 1st of June, 2020. >> >> Any objections? >> >> Andor >> >> >> >> >>> On 2020. Mar 4., at 18:45, Michael K. Edwards >> wrote: >>> >>> I think it would be useful for an EOL statement about 3.4.x to include a >>> policy on interoperability of newer ZooKeeper servers with 3.4.x client >>> code. Stacks that build on top of Kafka and Hadoop (I'm looking at you, >>> Spark) often wind up having an indirect dependency on a comically stale >>> ZooKeeper library. Even if this library isn't really exercised by the >>> client side of the stack, it's there in the mountain of jars; and when >>> application code also wants to use ZooKeeper more directly, using a newer >>> client library can get kind of messy. The approach I've taken has been >> to >>> rebuild large swathes of the stack around a consistent, recent ZooKeeper >>> build; but I think it would be relevant to a lot of people to know >> whether, >>> say, a 3.4.14 client will work reliably with a 3.6.x quorum. >>> >>> On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli >> wrote: >>> Il giorno mer 4 mar 2020 alle ore 17:23 Patrick Hunt ha scritto: > > It seems like we should have a stated/communicated policy around >> release > lifecycles before sending an EOL message. That way folks have some >> runway > to plan for the event, both near term (3.4) as well as long term. Shall we set a deadline ? Something like "3.4 will be EOL by the end of 2020" ? At this point we are only "discussing" about sending 3.4 to EOL, no decision has been made yet Enrico > > Patrick > > On Wed, Mar 4, 2020 at 5:16 AM Szalay-Bekő Máté < szalay.beko.m...@gmail.com> > wrote: > >> Also a minor thing to consider: we wanted to ask the HBase community >> to >> upgrade to ZooKeeper 3.5 before, and the conclusion there was that >> they >> will do so only when the EOL will be at least scheduled / announced on the >> ZooKeeper 3.4 versions. Maybe there are other ZooKeeper users as well who >> will not upgrade until they get 'an official' statement about the 3.4 >> versions. >> >> On Wed, Mar 4, 2020 at 1:44 PM Jordan Zimmerman < >> jor...@jordanzimmerman.com> >> wrote: >> >>> I'm +1 on this. We're planning to drop support for 3.4.x in the next >>> release of Apache Curator, FYI. >>> >>> -Jordan >>> On Mar 4, 2020, at 7:36 AM, Enrico Olivelli >> wrote: Hi, we are releasing 3.6.0 (I am waiting for mirrors to sync before updating the website). In my opinion it is time to officially send 3.4 branch to EOL status, >>> that is: - we are not expecting new releases - drop 3.4 from download area (it will stay on archives as usual) - strongly encourage people to update to 3.5/3.6 3.4 is far away from master branch and even from 3.6. There is a clean upgrade path from 3.4.LATEST to 3.5.7 and to 3.6 so users are able to upgrade. I am not sure we need a VOTE, if we simply agree I can drop 3.4 from the "dist" are as long as I push the new website. Best regards Enrico >>> >>> >> >> >>
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
+1. For EOL policy statement, just to throw something out here that i can think of: * Define what EOL means (such as: not supported by community dev team anymore, no future 3.4 releases .. still accessible at download page for X years..) and a date of EOL. * Provide guidelines for upgrading paths to 3.5 / 3.6. * State interoperability guarantees another post pointed out previously ^ On Wed, Apr 1, 2020 at 2:04 AM Andor Molnar wrote: > Hi folks, > > Based on Enrico’s latest post about a 3.4 client problem I’d like to push > this initiative. > Asking more senior members of the community what communicated policy is > needed exactly to say 3.4 is EoL? > > In terms of timing I’d like Patrick’s suggestion about 1st of June, 2020. > > Any objections? > > Andor > > > > > > On 2020. Mar 4., at 18:45, Michael K. Edwards > wrote: > > > > I think it would be useful for an EOL statement about 3.4.x to include a > > policy on interoperability of newer ZooKeeper servers with 3.4.x client > > code. Stacks that build on top of Kafka and Hadoop (I'm looking at you, > > Spark) often wind up having an indirect dependency on a comically stale > > ZooKeeper library. Even if this library isn't really exercised by the > > client side of the stack, it's there in the mountain of jars; and when > > application code also wants to use ZooKeeper more directly, using a newer > > client library can get kind of messy. The approach I've taken has been > to > > rebuild large swathes of the stack around a consistent, recent ZooKeeper > > build; but I think it would be relevant to a lot of people to know > whether, > > say, a 3.4.14 client will work reliably with a 3.6.x quorum. > > > > On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli > wrote: > > > >> Il giorno mer 4 mar 2020 alle ore 17:23 Patrick Hunt > >> ha scritto: > >>> > >>> It seems like we should have a stated/communicated policy around > release > >>> lifecycles before sending an EOL message. That way folks have some > runway > >>> to plan for the event, both near term (3.4) as well as long term. > >> > >> Shall we set a deadline ? > >> Something like "3.4 will be EOL by the end of 2020" ? > >> At this point we are only "discussing" about sending 3.4 to EOL, no > >> decision has been made yet > >> > >> > >> Enrico > >> > >> > >>> > >>> Patrick > >>> > >>> On Wed, Mar 4, 2020 at 5:16 AM Szalay-Bekő Máté < > >> szalay.beko.m...@gmail.com> > >>> wrote: > >>> > Also a minor thing to consider: we wanted to ask the HBase community > to > upgrade to ZooKeeper 3.5 before, and the conclusion there was that > they > will do so only when the EOL will be at least scheduled / announced on > >> the > ZooKeeper 3.4 versions. Maybe there are other ZooKeeper users as well > >> who > will not upgrade until they get 'an official' statement about the 3.4 > versions. > > On Wed, Mar 4, 2020 at 1:44 PM Jordan Zimmerman < > jor...@jordanzimmerman.com> > wrote: > > > I'm +1 on this. We're planning to drop support for 3.4.x in the next > > release of Apache Curator, FYI. > > > > -Jordan > > > >> On Mar 4, 2020, at 7:36 AM, Enrico Olivelli > wrote: > >> > >> Hi, > >> we are releasing 3.6.0 (I am waiting for mirrors to sync before > >> updating the website). > >> > >> In my opinion it is time to officially send 3.4 branch to EOL > >> status, > > that is: > >> - we are not expecting new releases > >> - drop 3.4 from download area (it will stay on archives as usual) > >> - strongly encourage people to update to 3.5/3.6 > >> > >> 3.4 is far away from master branch and even from 3.6. > >> There is a clean upgrade path from 3.4.LATEST to 3.5.7 and to 3.6 > >> so > >> users are able to upgrade. > >> > >> I am not sure we need a VOTE, if we simply agree I can drop 3.4 > >> from > >> the "dist" are as long as I push the new website. > >> > >> Best regards > >> Enrico > > > > > > >> > >
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
+1 (non-binding) On Wed, Apr 1, 2020 at 5:04 AM Andor Molnar wrote: > > Hi folks, > > Based on Enrico’s latest post about a 3.4 client problem I’d like to push > this initiative. > Asking more senior members of the community what communicated policy is > needed exactly to say 3.4 is EoL? > > In terms of timing I’d like Patrick’s suggestion about 1st of June, 2020. > > Any objections? > > Andor > > > > > > On 2020. Mar 4., at 18:45, Michael K. Edwards wrote: > > > > I think it would be useful for an EOL statement about 3.4.x to include a > > policy on interoperability of newer ZooKeeper servers with 3.4.x client > > code. Stacks that build on top of Kafka and Hadoop (I'm looking at you, > > Spark) often wind up having an indirect dependency on a comically stale > > ZooKeeper library. Even if this library isn't really exercised by the > > client side of the stack, it's there in the mountain of jars; and when > > application code also wants to use ZooKeeper more directly, using a newer > > client library can get kind of messy. The approach I've taken has been to > > rebuild large swathes of the stack around a consistent, recent ZooKeeper > > build; but I think it would be relevant to a lot of people to know whether, > > say, a 3.4.14 client will work reliably with a 3.6.x quorum. > > > > On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli wrote: > > > >> Il giorno mer 4 mar 2020 alle ore 17:23 Patrick Hunt > >> ha scritto: > >>> > >>> It seems like we should have a stated/communicated policy around release > >>> lifecycles before sending an EOL message. That way folks have some runway > >>> to plan for the event, both near term (3.4) as well as long term. > >> > >> Shall we set a deadline ? > >> Something like "3.4 will be EOL by the end of 2020" ? > >> At this point we are only "discussing" about sending 3.4 to EOL, no > >> decision has been made yet > >> > >> > >> Enrico > >> > >> > >>> > >>> Patrick > >>> > >>> On Wed, Mar 4, 2020 at 5:16 AM Szalay-Bekő Máté < > >> szalay.beko.m...@gmail.com> > >>> wrote: > >>> > Also a minor thing to consider: we wanted to ask the HBase community to > upgrade to ZooKeeper 3.5 before, and the conclusion there was that they > will do so only when the EOL will be at least scheduled / announced on > >> the > ZooKeeper 3.4 versions. Maybe there are other ZooKeeper users as well > >> who > will not upgrade until they get 'an official' statement about the 3.4 > versions. > > On Wed, Mar 4, 2020 at 1:44 PM Jordan Zimmerman < > jor...@jordanzimmerman.com> > wrote: > > > I'm +1 on this. We're planning to drop support for 3.4.x in the next > > release of Apache Curator, FYI. > > > > -Jordan > > > >> On Mar 4, 2020, at 7:36 AM, Enrico Olivelli > wrote: > >> > >> Hi, > >> we are releasing 3.6.0 (I am waiting for mirrors to sync before > >> updating the website). > >> > >> In my opinion it is time to officially send 3.4 branch to EOL > >> status, > > that is: > >> - we are not expecting new releases > >> - drop 3.4 from download area (it will stay on archives as usual) > >> - strongly encourage people to update to 3.5/3.6 > >> > >> 3.4 is far away from master branch and even from 3.6. > >> There is a clean upgrade path from 3.4.LATEST to 3.5.7 and to 3.6 > >> so > >> users are able to upgrade. > >> > >> I am not sure we need a VOTE, if we simply agree I can drop 3.4 > >> from > >> the "dist" are as long as I push the new website. > >> > >> Best regards > >> Enrico > > > > > > >> >
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
Hi folks, Based on Enrico’s latest post about a 3.4 client problem I’d like to push this initiative. Asking more senior members of the community what communicated policy is needed exactly to say 3.4 is EoL? In terms of timing I’d like Patrick’s suggestion about 1st of June, 2020. Any objections? Andor > On 2020. Mar 4., at 18:45, Michael K. Edwards wrote: > > I think it would be useful for an EOL statement about 3.4.x to include a > policy on interoperability of newer ZooKeeper servers with 3.4.x client > code. Stacks that build on top of Kafka and Hadoop (I'm looking at you, > Spark) often wind up having an indirect dependency on a comically stale > ZooKeeper library. Even if this library isn't really exercised by the > client side of the stack, it's there in the mountain of jars; and when > application code also wants to use ZooKeeper more directly, using a newer > client library can get kind of messy. The approach I've taken has been to > rebuild large swathes of the stack around a consistent, recent ZooKeeper > build; but I think it would be relevant to a lot of people to know whether, > say, a 3.4.14 client will work reliably with a 3.6.x quorum. > > On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli wrote: > >> Il giorno mer 4 mar 2020 alle ore 17:23 Patrick Hunt >> ha scritto: >>> >>> It seems like we should have a stated/communicated policy around release >>> lifecycles before sending an EOL message. That way folks have some runway >>> to plan for the event, both near term (3.4) as well as long term. >> >> Shall we set a deadline ? >> Something like "3.4 will be EOL by the end of 2020" ? >> At this point we are only "discussing" about sending 3.4 to EOL, no >> decision has been made yet >> >> >> Enrico >> >> >>> >>> Patrick >>> >>> On Wed, Mar 4, 2020 at 5:16 AM Szalay-Bekő Máté < >> szalay.beko.m...@gmail.com> >>> wrote: >>> Also a minor thing to consider: we wanted to ask the HBase community to upgrade to ZooKeeper 3.5 before, and the conclusion there was that they will do so only when the EOL will be at least scheduled / announced on >> the ZooKeeper 3.4 versions. Maybe there are other ZooKeeper users as well >> who will not upgrade until they get 'an official' statement about the 3.4 versions. On Wed, Mar 4, 2020 at 1:44 PM Jordan Zimmerman < jor...@jordanzimmerman.com> wrote: > I'm +1 on this. We're planning to drop support for 3.4.x in the next > release of Apache Curator, FYI. > > -Jordan > >> On Mar 4, 2020, at 7:36 AM, Enrico Olivelli wrote: >> >> Hi, >> we are releasing 3.6.0 (I am waiting for mirrors to sync before >> updating the website). >> >> In my opinion it is time to officially send 3.4 branch to EOL >> status, > that is: >> - we are not expecting new releases >> - drop 3.4 from download area (it will stay on archives as usual) >> - strongly encourage people to update to 3.5/3.6 >> >> 3.4 is far away from master branch and even from 3.6. >> There is a clean upgrade path from 3.4.LATEST to 3.5.7 and to 3.6 >> so >> users are able to upgrade. >> >> I am not sure we need a VOTE, if we simply agree I can drop 3.4 >> from >> the "dist" are as long as I push the new website. >> >> Best regards >> Enrico > > >>
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
I think it would be useful for an EOL statement about 3.4.x to include a policy on interoperability of newer ZooKeeper servers with 3.4.x client code. Stacks that build on top of Kafka and Hadoop (I'm looking at you, Spark) often wind up having an indirect dependency on a comically stale ZooKeeper library. Even if this library isn't really exercised by the client side of the stack, it's there in the mountain of jars; and when application code also wants to use ZooKeeper more directly, using a newer client library can get kind of messy. The approach I've taken has been to rebuild large swathes of the stack around a consistent, recent ZooKeeper build; but I think it would be relevant to a lot of people to know whether, say, a 3.4.14 client will work reliably with a 3.6.x quorum. On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli wrote: > Il giorno mer 4 mar 2020 alle ore 17:23 Patrick Hunt > ha scritto: > > > > It seems like we should have a stated/communicated policy around release > > lifecycles before sending an EOL message. That way folks have some runway > > to plan for the event, both near term (3.4) as well as long term. > > Shall we set a deadline ? > Something like "3.4 will be EOL by the end of 2020" ? > At this point we are only "discussing" about sending 3.4 to EOL, no > decision has been made yet > > > Enrico > > > > > > Patrick > > > > On Wed, Mar 4, 2020 at 5:16 AM Szalay-Bekő Máté < > szalay.beko.m...@gmail.com> > > wrote: > > > > > Also a minor thing to consider: we wanted to ask the HBase community to > > > upgrade to ZooKeeper 3.5 before, and the conclusion there was that they > > > will do so only when the EOL will be at least scheduled / announced on > the > > > ZooKeeper 3.4 versions. Maybe there are other ZooKeeper users as well > who > > > will not upgrade until they get 'an official' statement about the 3.4 > > > versions. > > > > > > On Wed, Mar 4, 2020 at 1:44 PM Jordan Zimmerman < > > > jor...@jordanzimmerman.com> > > > wrote: > > > > > > > I'm +1 on this. We're planning to drop support for 3.4.x in the next > > > > release of Apache Curator, FYI. > > > > > > > > -Jordan > > > > > > > > > On Mar 4, 2020, at 7:36 AM, Enrico Olivelli > > > wrote: > > > > > > > > > > Hi, > > > > > we are releasing 3.6.0 (I am waiting for mirrors to sync before > > > > > updating the website). > > > > > > > > > > In my opinion it is time to officially send 3.4 branch to EOL > status, > > > > that is: > > > > > - we are not expecting new releases > > > > > - drop 3.4 from download area (it will stay on archives as usual) > > > > > - strongly encourage people to update to 3.5/3.6 > > > > > > > > > > 3.4 is far away from master branch and even from 3.6. > > > > > There is a clean upgrade path from 3.4.LATEST to 3.5.7 and to 3.6 > so > > > > > users are able to upgrade. > > > > > > > > > > I am not sure we need a VOTE, if we simply agree I can drop 3.4 > from > > > > > the "dist" are as long as I push the new website. > > > > > > > > > > Best regards > > > > > Enrico > > > > > > > > > > > >
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli wrote: > Il giorno mer 4 mar 2020 alle ore 17:23 Patrick Hunt > ha scritto: > > > > It seems like we should have a stated/communicated policy around release > > lifecycles before sending an EOL message. That way folks have some runway > > to plan for the event, both near term (3.4) as well as long term. > > Shall we set a deadline ? > Something like "3.4 will be EOL by the end of 2020" ? > At this point we are only "discussing" about sending 3.4 to EOL, no > decision has been made yet > > That seems like a long time. Part of the reason I suggested having a policy/plan would make us more confident about deciding on a date. Why not June 1 2020? That would give folks 3 months before "official" EOL. The source/artifacts are still available, so it's not like folks would lose all access. Are there reasons to wait longer? We have b/w compat allowing fairly straightforward upgrade, no? Curator already has support, etc... What would be the reasons to wait? The other reason I suggested a communicated policy is that it should include releases other than 3.4. Again, providing information to the community on what we plan to do given the EOL of a particular release branch. Patrick > > Enrico > > > > > > Patrick > > > > On Wed, Mar 4, 2020 at 5:16 AM Szalay-Bekő Máté < > szalay.beko.m...@gmail.com> > > wrote: > > > > > Also a minor thing to consider: we wanted to ask the HBase community to > > > upgrade to ZooKeeper 3.5 before, and the conclusion there was that they > > > will do so only when the EOL will be at least scheduled / announced on > the > > > ZooKeeper 3.4 versions. Maybe there are other ZooKeeper users as well > who > > > will not upgrade until they get 'an official' statement about the 3.4 > > > versions. > > > > > > On Wed, Mar 4, 2020 at 1:44 PM Jordan Zimmerman < > > > jor...@jordanzimmerman.com> > > > wrote: > > > > > > > I'm +1 on this. We're planning to drop support for 3.4.x in the next > > > > release of Apache Curator, FYI. > > > > > > > > -Jordan > > > > > > > > > On Mar 4, 2020, at 7:36 AM, Enrico Olivelli > > > wrote: > > > > > > > > > > Hi, > > > > > we are releasing 3.6.0 (I am waiting for mirrors to sync before > > > > > updating the website). > > > > > > > > > > In my opinion it is time to officially send 3.4 branch to EOL > status, > > > > that is: > > > > > - we are not expecting new releases > > > > > - drop 3.4 from download area (it will stay on archives as usual) > > > > > - strongly encourage people to update to 3.5/3.6 > > > > > > > > > > 3.4 is far away from master branch and even from 3.6. > > > > > There is a clean upgrade path from 3.4.LATEST to 3.5.7 and to 3.6 > so > > > > > users are able to upgrade. > > > > > > > > > > I am not sure we need a VOTE, if we simply agree I can drop 3.4 > from > > > > > the "dist" are as long as I push the new website. > > > > > > > > > > Best regards > > > > > Enrico > > > > > > > > > > > >
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
Il giorno mer 4 mar 2020 alle ore 17:23 Patrick Hunt ha scritto: > > It seems like we should have a stated/communicated policy around release > lifecycles before sending an EOL message. That way folks have some runway > to plan for the event, both near term (3.4) as well as long term. Shall we set a deadline ? Something like "3.4 will be EOL by the end of 2020" ? At this point we are only "discussing" about sending 3.4 to EOL, no decision has been made yet Enrico > > Patrick > > On Wed, Mar 4, 2020 at 5:16 AM Szalay-Bekő Máté > wrote: > > > Also a minor thing to consider: we wanted to ask the HBase community to > > upgrade to ZooKeeper 3.5 before, and the conclusion there was that they > > will do so only when the EOL will be at least scheduled / announced on the > > ZooKeeper 3.4 versions. Maybe there are other ZooKeeper users as well who > > will not upgrade until they get 'an official' statement about the 3.4 > > versions. > > > > On Wed, Mar 4, 2020 at 1:44 PM Jordan Zimmerman < > > jor...@jordanzimmerman.com> > > wrote: > > > > > I'm +1 on this. We're planning to drop support for 3.4.x in the next > > > release of Apache Curator, FYI. > > > > > > -Jordan > > > > > > > On Mar 4, 2020, at 7:36 AM, Enrico Olivelli > > wrote: > > > > > > > > Hi, > > > > we are releasing 3.6.0 (I am waiting for mirrors to sync before > > > > updating the website). > > > > > > > > In my opinion it is time to officially send 3.4 branch to EOL status, > > > that is: > > > > - we are not expecting new releases > > > > - drop 3.4 from download area (it will stay on archives as usual) > > > > - strongly encourage people to update to 3.5/3.6 > > > > > > > > 3.4 is far away from master branch and even from 3.6. > > > > There is a clean upgrade path from 3.4.LATEST to 3.5.7 and to 3.6 so > > > > users are able to upgrade. > > > > > > > > I am not sure we need a VOTE, if we simply agree I can drop 3.4 from > > > > the "dist" are as long as I push the new website. > > > > > > > > Best regards > > > > Enrico > > > > > > > >
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
It seems like we should have a stated/communicated policy around release lifecycles before sending an EOL message. That way folks have some runway to plan for the event, both near term (3.4) as well as long term. Patrick On Wed, Mar 4, 2020 at 5:16 AM Szalay-Bekő Máté wrote: > Also a minor thing to consider: we wanted to ask the HBase community to > upgrade to ZooKeeper 3.5 before, and the conclusion there was that they > will do so only when the EOL will be at least scheduled / announced on the > ZooKeeper 3.4 versions. Maybe there are other ZooKeeper users as well who > will not upgrade until they get 'an official' statement about the 3.4 > versions. > > On Wed, Mar 4, 2020 at 1:44 PM Jordan Zimmerman < > jor...@jordanzimmerman.com> > wrote: > > > I'm +1 on this. We're planning to drop support for 3.4.x in the next > > release of Apache Curator, FYI. > > > > -Jordan > > > > > On Mar 4, 2020, at 7:36 AM, Enrico Olivelli > wrote: > > > > > > Hi, > > > we are releasing 3.6.0 (I am waiting for mirrors to sync before > > > updating the website). > > > > > > In my opinion it is time to officially send 3.4 branch to EOL status, > > that is: > > > - we are not expecting new releases > > > - drop 3.4 from download area (it will stay on archives as usual) > > > - strongly encourage people to update to 3.5/3.6 > > > > > > 3.4 is far away from master branch and even from 3.6. > > > There is a clean upgrade path from 3.4.LATEST to 3.5.7 and to 3.6 so > > > users are able to upgrade. > > > > > > I am not sure we need a VOTE, if we simply agree I can drop 3.4 from > > > the "dist" are as long as I push the new website. > > > > > > Best regards > > > Enrico > > > > >
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
Also a minor thing to consider: we wanted to ask the HBase community to upgrade to ZooKeeper 3.5 before, and the conclusion there was that they will do so only when the EOL will be at least scheduled / announced on the ZooKeeper 3.4 versions. Maybe there are other ZooKeeper users as well who will not upgrade until they get 'an official' statement about the 3.4 versions. On Wed, Mar 4, 2020 at 1:44 PM Jordan Zimmerman wrote: > I'm +1 on this. We're planning to drop support for 3.4.x in the next > release of Apache Curator, FYI. > > -Jordan > > > On Mar 4, 2020, at 7:36 AM, Enrico Olivelli wrote: > > > > Hi, > > we are releasing 3.6.0 (I am waiting for mirrors to sync before > > updating the website). > > > > In my opinion it is time to officially send 3.4 branch to EOL status, > that is: > > - we are not expecting new releases > > - drop 3.4 from download area (it will stay on archives as usual) > > - strongly encourage people to update to 3.5/3.6 > > > > 3.4 is far away from master branch and even from 3.6. > > There is a clean upgrade path from 3.4.LATEST to 3.5.7 and to 3.6 so > > users are able to upgrade. > > > > I am not sure we need a VOTE, if we simply agree I can drop 3.4 from > > the "dist" are as long as I push the new website. > > > > Best regards > > Enrico > >
Re: [DISCUSS] Sending 3.4 release line to End-Of-Life status
I'm +1 on this. We're planning to drop support for 3.4.x in the next release of Apache Curator, FYI. -Jordan > On Mar 4, 2020, at 7:36 AM, Enrico Olivelli wrote: > > Hi, > we are releasing 3.6.0 (I am waiting for mirrors to sync before > updating the website). > > In my opinion it is time to officially send 3.4 branch to EOL status, that is: > - we are not expecting new releases > - drop 3.4 from download area (it will stay on archives as usual) > - strongly encourage people to update to 3.5/3.6 > > 3.4 is far away from master branch and even from 3.6. > There is a clean upgrade path from 3.4.LATEST to 3.5.7 and to 3.6 so > users are able to upgrade. > > I am not sure we need a VOTE, if we simply agree I can drop 3.4 from > the "dist" are as long as I push the new website. > > Best regards > Enrico
[DISCUSS] Sending 3.4 release line to End-Of-Life status
Hi, we are releasing 3.6.0 (I am waiting for mirrors to sync before updating the website). In my opinion it is time to officially send 3.4 branch to EOL status, that is: - we are not expecting new releases - drop 3.4 from download area (it will stay on archives as usual) - strongly encourage people to update to 3.5/3.6 3.4 is far away from master branch and even from 3.6. There is a clean upgrade path from 3.4.LATEST to 3.5.7 and to 3.6 so users are able to upgrade. I am not sure we need a VOTE, if we simply agree I can drop 3.4 from the "dist" are as long as I push the new website. Best regards Enrico
