You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Fangmin Lv <lv...@gmail.com> on 2019/11/15 20:52:14 UTC
Re: Releasing 3.6.0 - ALPHA or not ?
I like the idea of keeping the naming simple and getting rid of 3.6.x. And
it seems reasonable
to me to keep beta for a while before we make it a 'stable' version even
though for the features
or fixes contributed from different individuals/orgs may have run on their
prod for a while.
I would suggest to cut 3.7.0 for the next branch, and only bump major
version if there is a real
big and non-compatible change we'd like to release.
Best,
Fangmin
On Wed, Oct 2, 2019 at 9:00 AM Zili Chen <wa...@gmail.com> wrote:
> Might be worth coming up with a proposal
> (ie review all the existing 4.x jira and other wish list and put a
> "proposal" wiki page together for 4.0?)
>
> An option is start with a couple of proposals pages under our
> wiki page[1] whether or not we process the major bump it
> helps memorize ideas and consensus of our community
> discussions and can be fast referred to.
>
> Best,
> tison.
>
> [1] https://cwiki.apache.org/confluence/display/HADOOP2/ZooKeeper
>
>
> Patrick Hunt <ph...@apache.org> 于2019年10月2日周三 下午11:40写道：
>
> > On Wed, Oct 2, 2019 at 2:22 AM Enrico Olivelli <eo...@gmail.com>
> > wrote:
> >
> > > If we release a 3.6.0-beta, shall the master point to 3.6.x ? or will
> we
> > > bump the version to 4.0.0 or 3.7.0 ?
> > > are we creating a branch-3.6, will it be open for new
> features/refactors
> > ?
> > >
> > >
> > Major version change means "not backward compatible". We've been at
> Apache
> > for > 10 years and never had to do this. Is it justified? ie what changes
> > would we make. I can think of a few; update the API to address some long
> > standing painpoints - ie version numbers are 32 bit ->64, fix the "epoch
> > overlaps zxid" which is a major PITA IMO, no checksum in the messages,
> > replace jute with protobuf, etc...
> >
> > That's going to break alot of downstreams. As such it would make sense to
> > have 3.7... while 4.0 was in play? Or keep b/w compat and address the
> > things I mentioned above (doable but more costly and time consuming, less
> > clean, etc...)
> >
> > Depends what we want to accomplish. Given the uptick in community
> activity
> > it might be a great time to try. Might be worth coming up with a proposal
> > (ie review all the existing 4.x jira and other wish list and put a
> > "proposal" wiki page together for 4.0?)
> >
> >
> > > Ideally once we cut a major release we move all the development and all
> > of
> > > the new features to master branch = next major release.
> > >
> > > In BookKeeper we have a concept of "latest stable" and "last released":
> > > - master branch -> not ready for production, not released yet
> > > - last released (3.6.0 in our case) -> latest and greatest, no blocker
> > > issues, it can be used in production, maybe not yet widespread, no more
> > API
> > > changes, allow minor improvements backported from master branch
> > > - latest stable (3.5.6) in out case-> last point release of latest
> > release
> > > branch, the branch has been around for some time and it is proven to be
> > > stable in production, only critical fixes accepted
> > >
> > > So I am leaning toward a 3.6.0 release, it is simpler for users (every
> > > role) to understand.
> > > People know that as soon as a major release is cut some issue may be
> > > encountered, this is why many companies wait to move to next major
> > version
> > > only after one or two point releases are available.
> > >
> > > btw I can live with a 3.6.0-beta, but with some constraint on a release
> > > within a couple of months, ZooKeeper community is more and more active,
> > it
> > > is becoming simpler to commit patches and cut releases.
> > >
> > >
> > Yes. Make it short whatever you do. But providing an "onramp" sounds
> like a
> > reasonable approach to me.
> >
> > Regards,
> >
> > Patrick
> >
> >
> > > I will also be happy to drive this release as RM, whatever path we
> decide
> > > as a community
> > >
> > > Enrico
> > >
> > >
> > >
> > >
> > >
> > >
> > > Il giorno mer 2 ott 2019 alle ore 11:04 Norbert Kalmar
> > > <nk...@cloudera.com.invalid> ha scritto:
> > >
> > > > So if I understand this, "3.6.0-beta" (let's cut the 1 here as maybe
> no
> > > > need for a second beta?) and after a fixed time (say about 3 month)
> > > > "3.6.0-beta2" OR "3.6.0" if it seems fit (vote on it again).
> > > > This sounds good to me, +1 (non-binding).
> > > >
> > > > Regards,
> > > > Norbert
> > > >
> > > > On Wed, Oct 2, 2019 at 10:54 AM Andor Molnar <an...@apache.org>
> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I second Pat’s suggestion about release in beta for a fixed period
> > and
> > > > > after that follow Norbert’s versioning scheme: 3.6.0-beta1,
> > > 3.6.0-beta2,
> > > > …
> > > > > , 3.6.0
> > > > >
> > > > > Regards,
> > > > > Andor
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > On 2019. Oct 2., at 2:23, Michael Han <ha...@apache.org> wrote:
> > > > > >
> > > > > > I am leaning towards release master as 3.6.0 as well, not with
> any
> > > > > suffix.
> > > > > > We don't have any pending unstable API for 3.6 (like dynamic
> > > > > > reconfiguration to 3.5) that justify the added overheads of
> using a
> > > non
> > > > > > standard, ZooKeeper specific versioning scheme for master branch.
> > > > > >
> > > > > > See
> > > > > >
> > > > >
> > > >
> > >
> >
> http://zookeeper-user.578899.n2.nabble.com/Question-about-3-5-0-stability-and-versioning-td7580927.html
> > > > > > for
> > > > > > some context on why the decision was made and the complains.
> > > > > >
> > > > > >
> > > > > > On Tue, Oct 1, 2019 at 7:11 AM Patrick Hunt <ph...@apache.org>
> > > wrote:
> > > > > >
> > > > > >> Enrico these are good ideas, thoughts below:
> > > > > >>
> > > > > >> On Tue, Oct 1, 2019 at 6:09 AM Norbert Kalmar
> > > > > <nkalmar@cloudera.com.invalid
> > > > > >>>
> > > > > >> wrote:
> > > > > >>
> > > > > >>> Hi,
> > > > > >>>
> > > > > >>> 3.5 had a lot of new features that wasn't really finalized, so
> > API
> > > > > >> changed
> > > > > >>> until stable 3.5 (3.5.5). But I don't think this is the case
> with
> > > > > 3.6.0,
> > > > > >> we
> > > > > >>> have complete and pretty much finalized features as far as I
> can
> > > > tell.
> > > > > >>> Also, it did confuse me that with the beta and alpha releases
> on
> > > 3.5
> > > > > >> minor
> > > > > >>> version jumped as well. So if we want to stick with alpha/beta
> > > > > qualifier,
> > > > > >>> let's keep it at 3.6.0-alpha and 3.6.0-beta (not like
> > 3.6.2-beta).
> > > > > >>>
> > > > > >>>
> > > > > >> That is a good point Norbert. We did try to say "alpha/beta is
> > > > unstable"
> > > > > >> (apis/code/etc...). That worked fairly well, but we were in that
> > > state
> > > > > for
> > > > > >> so long that people started using it in production and then got
> > > upset
> > > > > when
> > > > > >> we did change the APIs (whatever). As such I would say this is
> > only
> > > > > >> partially successful. Perhaps it would have been more successful
> > if
> > > we
> > > > > had
> > > > > >> limited the beta time down more, however folks kept increasing
> the
> > > > scope
> > > > > >> (by committing new features to 3.5 rather than trunk) and that
> > ended
> > > > up
> > > > > >> continually pushing out the dates.
> > > > > >>
> > > > > >>
> > > > > >>> I don't know any change that would justify an "alpha" version,
> so
> > > > > maybe a
> > > > > >>> beta would be better? But I'm also just fine releasing just
> > > "3.6.0".
> > > > > >> Bugfix
> > > > > >>> version is zero, everyone pretty much knows what that means :)
> > > > > >>>
> > > > > >>
> > > > > >> Perhaps a limited "beta" to allow folks to bang on it, then a
> > > planned
> > > > > move
> > > > > >> to "stable"? You could say we'll release it as beta for 3 months
> > > then
> > > > > move
> > > > > >> to stable if there are no major issues. The problem with just
> > > > releasing
> > > > > >> straight to stable is that many folks won't try it out from
> source
> > > and
> > > > > >> would only try a binary.
> > > > > >>
> > > > > >> Patrick
> > > > > >>
> > > > > >>
> > > > > >>>
> > > > > >>> So I lean toward leaving alpha and beta out of the version.
> > > > > >>>
> > > > > >>> Regards,
> > > > > >>> Norbert
> > > > > >>>
> > > > > >>> On Tue, Oct 1, 2019 at 2:34 PM Enrico Olivelli <
> > > eolivelli@gmail.com>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>> Hi,
> > > > > >>>> We are close to a release for 3.6.0, currently master branch
> is
> > > full
> > > > > of
> > > > > >>>> important features and important refactors.
> > > > > >>>>
> > > > > >>>> On the VOTE thread for 3.5.6 it came out that we could release
> > > 3.6.0
> > > > > as
> > > > > >>>> "ALPHA", here are my thoughts.
> > > > > >>>>
> > > > > >>>> I think we have at least these kind of "users":
> > > > > >>>> - Companies that run the Server on the most recent "stable"
> > > release
> > > > > >>>> - Companies that running a ZooKeeper cluster just because
> > another
> > > > > >> system
> > > > > >>>> depends on it (HBase, Kafka,Solr, Pulsar....)
> > > > > >>>> - Library maintainers (Kafka, BookKeeper, HBase), they depend
> > on a
> > > > > >>> version
> > > > > >>>> of the client or on some feature of the server
> > > > > >>>> - Application developers
> > > > > >>>> - Big companies that maintain their own forks and/or are using
> > the
> > > > > >>> "master"
> > > > > >>>> version
> > > > > >>>>
> > > > > >>>> With my library maintainer hat I feel I cannot depend on some
> > > > "ALPHA"
> > > > > >>>> version of ZooKeeper client and make my users setup an ALPHA
> > > > version
> > > > > >> of
> > > > > >>>> the server.
> > > > > >>>> It happened on BookKeeper for instance, we started to depend
> on
> > ZK
> > > > 3.5
> > > > > >>> but
> > > > > >>>> as it was BETA so we needed to revert back to 3.4.
> > > > > >>>> I think that some similar story happened in Kafka, now that we
> > > have
> > > > > 3.5
> > > > > >>>> with SSL support users are going to migrate.
> > > > > >>>>
> > > > > >>>> If there is no blocker issue on 3.6.0 I feel we should dare to
> > > > release
> > > > > >> it
> > > > > >>>> as "stable", we can always suggest users and companies to try
> > out
> > > > > >> current
> > > > > >>>> master and give feedback.
> > > > > >>>>
> > > > > >>>> I am new to this story of tagging as "ALPHA"/"BETA" on
> > ZooKeeper,
> > > > but
> > > > > >> as
> > > > > >>> an
> > > > > >>>> user and library maintainer I suffered a lot that '-ALPHA' and
> > > > '-BETA'
> > > > > >>>> suffixes.
> > > > > >>>> I know that ZooKeeper is the core of most of the other systems
> > and
> > > > we
> > > > > >>>> should not suggest to use something that it is "experimental",
> > but
> > > > as
> > > > > >> far
> > > > > >>>> as I know we are taking great care about being backward
> > compatible
> > > > and
> > > > > >>>> about the quality of our code base.
> > > > > >>>>
> > > > > >>>> Other opinions ?
> > > > > >>>>
> > > > > >>>> Enrico
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Releasing 3.6.0 - ALPHA or not ?
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
The 3.5.x-ALPHA scheme was extremely confusing for ZK's user base (doubly so given how long it remained in alpha then beta). Many companies used it anyway so adding the qualifier didn't serve much purpose. Better to leave it off and communicate known issues through standard channels.
My 0.02
-Jordan
> On Nov 15, 2019, at 3:52 PM, Fangmin Lv <lv...@gmail.com> wrote:
>
> I like the idea of keeping the naming simple and getting rid of 3.6.x. And
> it seems reasonable
> to me to keep beta for a while before we make it a 'stable' version even
> though for the features
> or fixes contributed from different individuals/orgs may have run on their
> prod for a while.
>
> I would suggest to cut 3.7.0 for the next branch, and only bump major
> version if there is a real
> big and non-compatible change we'd like to release.
>
> Best,
> Fangmin
>
>
> On Wed, Oct 2, 2019 at 9:00 AM Zili Chen <wa...@gmail.com> wrote:
>
>> Might be worth coming up with a proposal
>> (ie review all the existing 4.x jira and other wish list and put a
>> "proposal" wiki page together for 4.0?)
>>
>> An option is start with a couple of proposals pages under our
>> wiki page[1] whether or not we process the major bump it
>> helps memorize ideas and consensus of our community
>> discussions and can be fast referred to.
>>
>> Best,
>> tison.
>>
>> [1] https://cwiki.apache.org/confluence/display/HADOOP2/ZooKeeper
>>
>>
>> Patrick Hunt <ph...@apache.org> 于2019年10月2日周三 下午11:40写道：
>>
>>> On Wed, Oct 2, 2019 at 2:22 AM Enrico Olivelli <eo...@gmail.com>
>>> wrote:
>>>
>>>> If we release a 3.6.0-beta, shall the master point to 3.6.x ? or will
>> we
>>>> bump the version to 4.0.0 or 3.7.0 ?
>>>> are we creating a branch-3.6, will it be open for new
>> features/refactors
>>> ?
>>>>
>>>>
>>> Major version change means "not backward compatible". We've been at
>> Apache
>>> for > 10 years and never had to do this. Is it justified? ie what changes
>>> would we make. I can think of a few; update the API to address some long
>>> standing painpoints - ie version numbers are 32 bit ->64, fix the "epoch
>>> overlaps zxid" which is a major PITA IMO, no checksum in the messages,
>>> replace jute with protobuf, etc...
>>>
>>> That's going to break alot of downstreams. As such it would make sense to
>>> have 3.7... while 4.0 was in play? Or keep b/w compat and address the
>>> things I mentioned above (doable but more costly and time consuming, less
>>> clean, etc...)
>>>
>>> Depends what we want to accomplish. Given the uptick in community
>> activity
>>> it might be a great time to try. Might be worth coming up with a proposal
>>> (ie review all the existing 4.x jira and other wish list and put a
>>> "proposal" wiki page together for 4.0?)
>>>
>>>
>>>> Ideally once we cut a major release we move all the development and all
>>> of
>>>> the new features to master branch = next major release.
>>>>
>>>> In BookKeeper we have a concept of "latest stable" and "last released":
>>>> - master branch -> not ready for production, not released yet
>>>> - last released (3.6.0 in our case) -> latest and greatest, no blocker
>>>> issues, it can be used in production, maybe not yet widespread, no more
>>> API
>>>> changes, allow minor improvements backported from master branch
>>>> - latest stable (3.5.6) in out case-> last point release of latest
>>> release
>>>> branch, the branch has been around for some time and it is proven to be
>>>> stable in production, only critical fixes accepted
>>>>
>>>> So I am leaning toward a 3.6.0 release, it is simpler for users (every
>>>> role) to understand.
>>>> People know that as soon as a major release is cut some issue may be
>>>> encountered, this is why many companies wait to move to next major
>>> version
>>>> only after one or two point releases are available.
>>>>
>>>> btw I can live with a 3.6.0-beta, but with some constraint on a release
>>>> within a couple of months, ZooKeeper community is more and more active,
>>> it
>>>> is becoming simpler to commit patches and cut releases.
>>>>
>>>>
>>> Yes. Make it short whatever you do. But providing an "onramp" sounds
>> like a
>>> reasonable approach to me.
>>>
>>> Regards,
>>>
>>> Patrick
>>>
>>>
>>>> I will also be happy to drive this release as RM, whatever path we
>> decide
>>>> as a community
>>>>
>>>> Enrico
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Il giorno mer 2 ott 2019 alle ore 11:04 Norbert Kalmar
>>>> <nk...@cloudera.com.invalid> ha scritto:
>>>>
>>>>> So if I understand this, "3.6.0-beta" (let's cut the 1 here as maybe
>> no
>>>>> need for a second beta?) and after a fixed time (say about 3 month)
>>>>> "3.6.0-beta2" OR "3.6.0" if it seems fit (vote on it again).
>>>>> This sounds good to me, +1 (non-binding).
>>>>>
>>>>> Regards,
>>>>> Norbert
>>>>>
>>>>> On Wed, Oct 2, 2019 at 10:54 AM Andor Molnar <an...@apache.org>
>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I second Pat’s suggestion about release in beta for a fixed period
>>> and
>>>>>> after that follow Norbert’s versioning scheme: 3.6.0-beta1,
>>>> 3.6.0-beta2,
>>>>> …
>>>>>> , 3.6.0
>>>>>>
>>>>>> Regards,
>>>>>> Andor
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 2019. Oct 2., at 2:23, Michael Han <ha...@apache.org> wrote:
>>>>>>>
>>>>>>> I am leaning towards release master as 3.6.0 as well, not with
>> any
>>>>>> suffix.
>>>>>>> We don't have any pending unstable API for 3.6 (like dynamic
>>>>>>> reconfiguration to 3.5) that justify the added overheads of
>> using a
>>>> non
>>>>>>> standard, ZooKeeper specific versioning scheme for master branch.
>>>>>>>
>>>>>>> See
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> http://zookeeper-user.578899.n2.nabble.com/Question-about-3-5-0-stability-and-versioning-td7580927.html
>>>>>>> for
>>>>>>> some context on why the decision was made and the complains.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Oct 1, 2019 at 7:11 AM Patrick Hunt <ph...@apache.org>
>>>> wrote:
>>>>>>>
>>>>>>>> Enrico these are good ideas, thoughts below:
>>>>>>>>
>>>>>>>> On Tue, Oct 1, 2019 at 6:09 AM Norbert Kalmar
>>>>>> <nkalmar@cloudera.com.invalid
>>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> 3.5 had a lot of new features that wasn't really finalized, so
>>> API
>>>>>>>> changed
>>>>>>>>> until stable 3.5 (3.5.5). But I don't think this is the case
>> with
>>>>>> 3.6.0,
>>>>>>>> we
>>>>>>>>> have complete and pretty much finalized features as far as I
>> can
>>>>> tell.
>>>>>>>>> Also, it did confuse me that with the beta and alpha releases
>> on
>>>> 3.5
>>>>>>>> minor
>>>>>>>>> version jumped as well. So if we want to stick with alpha/beta
>>>>>> qualifier,
>>>>>>>>> let's keep it at 3.6.0-alpha and 3.6.0-beta (not like
>>> 3.6.2-beta).
>>>>>>>>>
>>>>>>>>>
>>>>>>>> That is a good point Norbert. We did try to say "alpha/beta is
>>>>> unstable"
>>>>>>>> (apis/code/etc...). That worked fairly well, but we were in that
>>>> state
>>>>>> for
>>>>>>>> so long that people started using it in production and then got
>>>> upset
>>>>>> when
>>>>>>>> we did change the APIs (whatever). As such I would say this is
>>> only
>>>>>>>> partially successful. Perhaps it would have been more successful
>>> if
>>>> we
>>>>>> had
>>>>>>>> limited the beta time down more, however folks kept increasing
>> the
>>>>> scope
>>>>>>>> (by committing new features to 3.5 rather than trunk) and that
>>> ended
>>>>> up
>>>>>>>> continually pushing out the dates.
>>>>>>>>
>>>>>>>>
>>>>>>>>> I don't know any change that would justify an "alpha" version,
>> so
>>>>>> maybe a
>>>>>>>>> beta would be better? But I'm also just fine releasing just
>>>> "3.6.0".
>>>>>>>> Bugfix
>>>>>>>>> version is zero, everyone pretty much knows what that means :)
>>>>>>>>>
>>>>>>>>
>>>>>>>> Perhaps a limited "beta" to allow folks to bang on it, then a
>>>> planned
>>>>>> move
>>>>>>>> to "stable"? You could say we'll release it as beta for 3 months
>>>> then
>>>>>> move
>>>>>>>> to stable if there are no major issues. The problem with just
>>>>> releasing
>>>>>>>> straight to stable is that many folks won't try it out from
>> source
>>>> and
>>>>>>>> would only try a binary.
>>>>>>>>
>>>>>>>> Patrick
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> So I lean toward leaving alpha and beta out of the version.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Norbert
>>>>>>>>>
>>>>>>>>> On Tue, Oct 1, 2019 at 2:34 PM Enrico Olivelli <
>>>> eolivelli@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> We are close to a release for 3.6.0, currently master branch
>> is
>>>> full
>>>>>> of
>>>>>>>>>> important features and important refactors.
>>>>>>>>>>
>>>>>>>>>> On the VOTE thread for 3.5.6 it came out that we could release
>>>> 3.6.0
>>>>>> as
>>>>>>>>>> "ALPHA", here are my thoughts.
>>>>>>>>>>
>>>>>>>>>> I think we have at least these kind of "users":
>>>>>>>>>> - Companies that run the Server on the most recent "stable"
>>>> release
>>>>>>>>>> - Companies that running a ZooKeeper cluster just because
>>> another
>>>>>>>> system
>>>>>>>>>> depends on it (HBase, Kafka,Solr, Pulsar....)
>>>>>>>>>> - Library maintainers (Kafka, BookKeeper, HBase), they depend
>>> on a
>>>>>>>>> version
>>>>>>>>>> of the client or on some feature of the server
>>>>>>>>>> - Application developers
>>>>>>>>>> - Big companies that maintain their own forks and/or are using
>>> the
>>>>>>>>> "master"
>>>>>>>>>> version
>>>>>>>>>>
>>>>>>>>>> With my library maintainer hat I feel I cannot depend on some
>>>>> "ALPHA"
>>>>>>>>>> version of ZooKeeper client and make my users setup an ALPHA
>>>>> version
>>>>>>>> of
>>>>>>>>>> the server.
>>>>>>>>>> It happened on BookKeeper for instance, we started to depend
>> on
>>> ZK
>>>>> 3.5
>>>>>>>>> but
>>>>>>>>>> as it was BETA so we needed to revert back to 3.4.
>>>>>>>>>> I think that some similar story happened in Kafka, now that we
>>>> have
>>>>>> 3.5
>>>>>>>>>> with SSL support users are going to migrate.
>>>>>>>>>>
>>>>>>>>>> If there is no blocker issue on 3.6.0 I feel we should dare to
>>>>> release
>>>>>>>> it
>>>>>>>>>> as "stable", we can always suggest users and companies to try
>>> out
>>>>>>>> current
>>>>>>>>>> master and give feedback.
>>>>>>>>>>
>>>>>>>>>> I am new to this story of tagging as "ALPHA"/"BETA" on
>>> ZooKeeper,
>>>>> but
>>>>>>>> as
>>>>>>>>> an
>>>>>>>>>> user and library maintainer I suffered a lot that '-ALPHA' and
>>>>> '-BETA'
>>>>>>>>>> suffixes.
>>>>>>>>>> I know that ZooKeeper is the core of most of the other systems
>>> and
>>>>> we
>>>>>>>>>> should not suggest to use something that it is "experimental",
>>> but
>>>>> as
>>>>>>>> far
>>>>>>>>>> as I know we are taking great care about being backward
>>> compatible
>>>>> and
>>>>>>>>>> about the quality of our code base.
>>>>>>>>>>
>>>>>>>>>> Other opinions ?
>>>>>>>>>>
>>>>>>>>>> Enrico
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>