You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ratis.apache.org by "Elek, Marton" <el...@apache.org> on 2021/01/06 12:28:25 UTC
Re: ratis 1.1.0 and ratis-thirdparty 0.6.0 release
Thanks the suggestions.
Does anybody has a list of the in-compatible changes?
If there is no objection, I will:
1. start the release process for the THIRDPARTY
2. Change the version on master to 2.0 and fork a 1.1 branch
We need a list of the incompatible changes. We can either fork 1.1 from
the master and revert them OR fork from 1.0 and add the changes one bye on.
(We have 119 commits since 1.0 as far as I see)
Marton
On 12/2/20 3:05 PM, Tsz Wo Sze wrote:
> Thanks Marton and Attila for bringing this up.
>
> For 2.0, we should wait for RATIS-1181. It defines APIs for StateMachine
> implementations so that they do not have to use the private APIs.
>
> We may consider releasing 1.1. In this case, we should cherry-pick bug
> fixes and avoid the incompatible changes.
>
> Tsz-Wo
>
> On Wed, Dec 2, 2020 at 8:22 PM Attila Doroszlai <ad...@apache.org>
> wrote:
>
>>> Is there any important fix which must be included?
>>
>> Recently there was some discussion here about incompatible changes to
>> Ratis since 1.0. Nicholas mentioned that the next release could be
>> 2.0 instead of 1.1 and declare it's not fully backward compatible. Is
>> the async API stable now so that we can avoid the same situation soon
>> after the next release? (There are some outstanding PRs related to
>> it.) Or would it make sense to cut a release branch for 1.1 without
>> changes related to RATIS-979 and apply other fixes?
>>
>> thanks,
>> Attila
>>
>
Re: ratis 1.1.0 and ratis-thirdparty 0.6.0 release
Posted by Tsz Wo Sze <sz...@gmail.com>.
Sure, we should maintain wire compatibility whenever possible.
Below is a commented about ratis 2.0.0 copied from
https://github.com/apache/ozone/pull/1763#issuecomment-756092110
- ratis-1.0.0 was released on Wed Jul 8 15:09:29 2020:
- The first incompatible change after ratis-1.0.0 was committed on Wed Sep
16 13:31:28 2020 (07543a4)
For compatibility, create branch-1.1 to include everything up to 07543a4,
exclusively. We can release ratis-1.1.0 from branch-1.1 in the future.
Applications using ratis-1.0.0 can upgrade to ratis-1.1.0 without any
compatibility issues.
Then, change the ratis version in master to 2.0.0-SNAPSHOT. We will release
ratis-2.0.0 from the master. Applications (such as Ozone) like to change
their code to address the incompatible changes can move to ratis-2.0.0.
Also, Ozone can keep using the ratis snapshots (i.e. this pull request)
from master as before.
Thanks
Tsz-Wo
On Fri, Jan 15, 2021 at 1:51 AM Arpit Agarwal <aa...@cloudera.com.invalid>
wrote:
> Do we have a list of incompatible changes? Ratis is used as a dependency,
> so we cannot break compatibility in a minor release.
>
> It is especially troublesome if there is wire incompatibility i.e. older
> client cannot talk to newer server or vice versa. Wire compatibility should
> be preserved even across major versions.
>
> On Fri, Jan 8, 2021 at 1:03 AM Elek, Marton <el...@apache.org> wrote:
>
> >
> > If Ozone is updated to the latest master, I am not interested to cut the
> > 1.1 and do 1.1 release.
> >
> > We need Ratis 2.0 release in this case for Ozone 1.1.
> >
> > Is there anything pending to the master which should be merged before
> > the first 2.0 RC based on the master?
> >
> > Anybody volunteering to create RC / do RM work?
> >
> > Thanks,
> > Marton
> >
>
Re: ratis 1.1.0 and ratis-thirdparty 0.6.0 release
Posted by Arpit Agarwal <aa...@cloudera.com.INVALID>.
Do we have a list of incompatible changes? Ratis is used as a dependency,
so we cannot break compatibility in a minor release.
It is especially troublesome if there is wire incompatibility i.e. older
client cannot talk to newer server or vice versa. Wire compatibility should
be preserved even across major versions.
On Fri, Jan 8, 2021 at 1:03 AM Elek, Marton <el...@apache.org> wrote:
>
> If Ozone is updated to the latest master, I am not interested to cut the
> 1.1 and do 1.1 release.
>
> We need Ratis 2.0 release in this case for Ozone 1.1.
>
> Is there anything pending to the master which should be merged before
> the first 2.0 RC based on the master?
>
> Anybody volunteering to create RC / do RM work?
>
> Thanks,
> Marton
>
Re: ratis 1.1.0 and ratis-thirdparty 0.6.0 release
Posted by "Elek, Marton" <el...@apache.org>.
If Ozone is updated to the latest master, I am not interested to cut the
1.1 and do 1.1 release.
We need Ratis 2.0 release in this case for Ozone 1.1.
Is there anything pending to the master which should be merged before
the first 2.0 RC based on the master?
Anybody volunteering to create RC / do RM work?
Thanks,
Marton
Re: ratis 1.1.0 and ratis-thirdparty 0.6.0 release
Posted by Rui Wang <am...@apache.org>.
On Wed, Jan 6, 2021 at 6:25 AM Tsz Wo Sze <sz...@gmail.com> wrote:
> Hi Elek,
>
> The first incompatible change after 1.0 is
> 07543a44c00e680cec24c1f18d9aa625b09f6e5e . For simplicity, I suggest to
> fork 1.1 branch from there. If there is a need in the future, we may
> cherry-pick other bug fixes from the master 2.0 branch to the 1.1 branch.
>
My understanding is that the suggestion here is to fork a branch before the
first incompatible commit (e.g. 07543a44c00e680cec24c1f18d9aa625b09f6e5e).
However, as in Ozone we have to upgrade to 1.1.0-c5eafb9-SNAPSHOT (
https://github.com/apache/ozone/pull/1728). Will it make sense to cut the
1.0 branch from at least that version?
-Rui
>
> Thanks a lot for taking care of this.
> Tsz-Wo
>
>
> On Wed, Jan 6, 2021 at 9:16 PM runzhiwang <ru...@gmail.com> wrote:
>
> > Ozone has upgrade ratis to 1.1.0-c5eafb9-SNAPSHOT, and has already
> address
> > some incompatible changes including that of RATIS-1181.
> > Please wait for me, I will submit a PR in ozone to address the other
> > incompatible changes.
> >
> > Thanks,
> > runzhiwang
> >
> > Elek, Marton <el...@apache.org> 于2021年1月6日周三 下午8:28写道：
> >
> > >
> > > Thanks the suggestions.
> > >
> > > Does anybody has a list of the in-compatible changes?
> > >
> > >
> > > If there is no objection, I will:
> > >
> > > 1. start the release process for the THIRDPARTY
> > > 2. Change the version on master to 2.0 and fork a 1.1 branch
> > >
> > > We need a list of the incompatible changes. We can either fork 1.1 from
> > > the master and revert them OR fork from 1.0 and add the changes one bye
> > on.
> > >
> > > (We have 119 commits since 1.0 as far as I see)
> > >
> > > Marton
> > >
> > > On 12/2/20 3:05 PM, Tsz Wo Sze wrote:
> > > > Thanks Marton and Attila for bringing this up.
> > > >
> > > > For 2.0, we should wait for RATIS-1181. It defines APIs for
> > StateMachine
> > > > implementations so that they do not have to use the private APIs.
> > > >
> > > > We may consider releasing 1.1. In this case, we should cherry-pick
> bug
> > > > fixes and avoid the incompatible changes.
> > > >
> > > > Tsz-Wo
> > > >
> > > > On Wed, Dec 2, 2020 at 8:22 PM Attila Doroszlai <
> adoroszlai@apache.org
> > >
> > > > wrote:
> > > >
> > > >>> Is there any important fix which must be included?
> > > >>
> > > >> Recently there was some discussion here about incompatible changes
> to
> > > >> Ratis since 1.0. Nicholas mentioned that the next release could be
> > > >> 2.0 instead of 1.1 and declare it's not fully backward compatible.
> Is
> > > >> the async API stable now so that we can avoid the same situation
> soon
> > > >> after the next release? (There are some outstanding PRs related to
> > > >> it.) Or would it make sense to cut a release branch for 1.1 without
> > > >> changes related to RATIS-979 and apply other fixes?
> > > >>
> > > >> thanks,
> > > >> Attila
> > > >>
> > > >
> > >
> >
>
Re: ratis 1.1.0 and ratis-thirdparty 0.6.0 release
Posted by Tsz Wo Sze <sz...@gmail.com>.
Hi Elek,
The first incompatible change after 1.0 is
07543a44c00e680cec24c1f18d9aa625b09f6e5e . For simplicity, I suggest to
fork 1.1 branch from there. If there is a need in the future, we may
cherry-pick other bug fixes from the master 2.0 branch to the 1.1 branch.
Thanks a lot for taking care of this.
Tsz-Wo
On Wed, Jan 6, 2021 at 9:16 PM runzhiwang <ru...@gmail.com> wrote:
> Ozone has upgrade ratis to 1.1.0-c5eafb9-SNAPSHOT, and has already address
> some incompatible changes including that of RATIS-1181.
> Please wait for me, I will submit a PR in ozone to address the other
> incompatible changes.
>
> Thanks,
> runzhiwang
>
> Elek, Marton <el...@apache.org> 于2021年1月6日周三 下午8:28写道：
>
> >
> > Thanks the suggestions.
> >
> > Does anybody has a list of the in-compatible changes?
> >
> >
> > If there is no objection, I will:
> >
> > 1. start the release process for the THIRDPARTY
> > 2. Change the version on master to 2.0 and fork a 1.1 branch
> >
> > We need a list of the incompatible changes. We can either fork 1.1 from
> > the master and revert them OR fork from 1.0 and add the changes one bye
> on.
> >
> > (We have 119 commits since 1.0 as far as I see)
> >
> > Marton
> >
> > On 12/2/20 3:05 PM, Tsz Wo Sze wrote:
> > > Thanks Marton and Attila for bringing this up.
> > >
> > > For 2.0, we should wait for RATIS-1181. It defines APIs for
> StateMachine
> > > implementations so that they do not have to use the private APIs.
> > >
> > > We may consider releasing 1.1. In this case, we should cherry-pick bug
> > > fixes and avoid the incompatible changes.
> > >
> > > Tsz-Wo
> > >
> > > On Wed, Dec 2, 2020 at 8:22 PM Attila Doroszlai <adoroszlai@apache.org
> >
> > > wrote:
> > >
> > >>> Is there any important fix which must be included?
> > >>
> > >> Recently there was some discussion here about incompatible changes to
> > >> Ratis since 1.0. Nicholas mentioned that the next release could be
> > >> 2.0 instead of 1.1 and declare it's not fully backward compatible. Is
> > >> the async API stable now so that we can avoid the same situation soon
> > >> after the next release? (There are some outstanding PRs related to
> > >> it.) Or would it make sense to cut a release branch for 1.1 without
> > >> changes related to RATIS-979 and apply other fixes?
> > >>
> > >> thanks,
> > >> Attila
> > >>
> > >
> >
>
Re: ratis 1.1.0 and ratis-thirdparty 0.6.0 release
Posted by runzhiwang <ru...@gmail.com>.
Ozone has upgrade ratis to 1.1.0-c5eafb9-SNAPSHOT, and has already address
some incompatible changes including that of RATIS-1181.
Please wait for me, I will submit a PR in ozone to address the other
incompatible changes.
Thanks,
runzhiwang
Elek, Marton <el...@apache.org> 于2021年1月6日周三 下午8:28写道：
>
> Thanks the suggestions.
>
> Does anybody has a list of the in-compatible changes?
>
>
> If there is no objection, I will:
>
> 1. start the release process for the THIRDPARTY
> 2. Change the version on master to 2.0 and fork a 1.1 branch
>
> We need a list of the incompatible changes. We can either fork 1.1 from
> the master and revert them OR fork from 1.0 and add the changes one bye on.
>
> (We have 119 commits since 1.0 as far as I see)
>
> Marton
>
> On 12/2/20 3:05 PM, Tsz Wo Sze wrote:
> > Thanks Marton and Attila for bringing this up.
> >
> > For 2.0, we should wait for RATIS-1181. It defines APIs for StateMachine
> > implementations so that they do not have to use the private APIs.
> >
> > We may consider releasing 1.1. In this case, we should cherry-pick bug
> > fixes and avoid the incompatible changes.
> >
> > Tsz-Wo
> >
> > On Wed, Dec 2, 2020 at 8:22 PM Attila Doroszlai <ad...@apache.org>
> > wrote:
> >
> >>> Is there any important fix which must be included?
> >>
> >> Recently there was some discussion here about incompatible changes to
> >> Ratis since 1.0. Nicholas mentioned that the next release could be
> >> 2.0 instead of 1.1 and declare it's not fully backward compatible. Is
> >> the async API stable now so that we can avoid the same situation soon
> >> after the next release? (There are some outstanding PRs related to
> >> it.) Or would it make sense to cut a release branch for 1.1 without
> >> changes related to RATIS-979 and apply other fixes?
> >>
> >> thanks,
> >> Attila
> >>
> >
>