[RESULT][VOTE] Release Apache Flink 1.3.0 (RC3)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[RESULT][VOTE] Release Apache Flink 1.3.0 (RC3)

Robert Metzger
Thanks a lot for all your responses on the point Till raised.
It seems that we have an agreement to release this RC as Flink 1.3.0.
I'll include a note into the release announcement regarding the state
descriptor issue.


Thanks also for all the release testing and the votes.

+1 votes:
- Chesnay
- Robert (binding)
- jincheng sun
- Aljoscha (binding)
- Gordon
- Greg (binding)

That's 6 votes, out of which 3 are binding.
Therefore, I'll release RC3 as Flink 1.3.0!



On Wed, May 31, 2017 at 2:08 PM, Till Rohrmann <[hidden email]> wrote:

> I would be ok to quickly release 1.3.1 once the the respective PRs have
> been merged.
>
> Just for your information, I'm not yet through with the testing of the type
> serializer upgrade feature, though.
>
> Cheers,
> Till
>
> On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
> [hidden email]> wrote:
>
> > +1 for releasing now and providing a 1.3.1 release soon.
> >
> > > Am 31.05.2017 um 11:02 schrieb Gyula Fóra <[hidden email]>:
> > >
> > > Hi All,
> > >
> > > I also lean towards getting the release out as soon as possible given
> > that
> > > it had been delayed quite a bit and there is no major issue without a
> > > straightforward workaround (agreeing with Nico and Kostas). I am sure
> > once
> > > people will start using the new features we will see more issues that
> > > should be fixed asap in 1.3.1.
> > >
> > > Regarding the critical bug Till had found, we could add a line about it
> > to
> > > the release notes so that people don't get blocked by it as there is a
> > > workaround possible.
> > >
> > > Regards,
> > > Gyula
> > >
> > >
> > > Kostas Kloudas <[hidden email]> ezt írta (időpont: 2017.
> > máj.
> > > 31., Sze, 10:53):
> > >
> > >> Hi all,
> > >>
> > >> I also tend to agree with the argument that says a release should be
> out
> > >> as soon as possible, given that 1) it improves usability/functionality
> > and
> > >> 2) at a minimum, it does not include new known bugs. The arguments are
> > >> more or less aligned with Nico’s response on the matter.
> > >>
> > >> Focusing on the bug that spiked the current discussion, I agree with
> > Till
> > >> that this is alarming, as it passed all previous testing efforts, but
> I
> > >> have to
> > >> add that if nobody so far encountered it, we could release 1.3 now and
> > fix
> > >> it in the upcoming 1.3.1.
> > >>
> > >> Kostas
> > >>
> > >>> On May 31, 2017, at 10:20 AM, Nico Kruber <[hidden email]>
> > >> wrote:
> > >>>
> > >>> IMHO, any release that improves things and does not break anything is
> > >> worth
> > >>> releasing and should not be blocked on bugs that it did not cause.
> > >>> There will always be a next (minor/major) release that may fix this
> at
> > a
> > >> later
> > >>> time, given that the time between releases is not too high.
> > >>>
> > >>> Consider someone waiting for a bugfix/feature that made it into 1.3.0
> > >> who--if
> > >>> delayed--would have to wait even longer for "his" bugfix/feature. Any
> > new
> > >>> bugfixes (and there will always be more) can wait a few more days or
> > >> even a few
> > >>> weeks and may be fixed in 1.3.1 or so.
> > >>>
> > >>>
> > >>> Nico
> > >>>
> > >>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
> > >>>> - Not sure whether it's a good argument to defer fixing major bugs
> > >> because
> > >>>> they have not been introduced with 1.3.0. It's actually alarming
> that
> > >> these
> > >>>> things have not been found earlier given that we test our releases
> > >>>> thoroughly.
> > >>>
> > >>
> > >>
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [RESULT][VOTE] Release Apache Flink 1.3.0 (RC3)

Tzu-Li (Gordon) Tai
One suggestion for future major release announcements:

I propose that we add a list of deprecated / breaking API changes in the announcement of major releases.
Although @PublicEnvolving API is not guaranteed to not change across releases, it would still be nice that there’s a proper announcement when changing or deprecating them.
Ideally, to avoid collecting the whole list during the release which most likely wouldn’t work, we can collect this list on the wiki during the development cycle.


On 31 May 2017 at 2:22:34 PM, Robert Metzger ([hidden email]) wrote:

Thanks a lot for all your responses on the point Till raised.  
It seems that we have an agreement to release this RC as Flink 1.3.0.  
I'll include a note into the release announcement regarding the state  
descriptor issue.  


Thanks also for all the release testing and the votes.  

+1 votes:  
- Chesnay  
- Robert (binding)  
- jincheng sun  
- Aljoscha (binding)  
- Gordon  
- Greg (binding)  

That's 6 votes, out of which 3 are binding.  
Therefore, I'll release RC3 as Flink 1.3.0!  



On Wed, May 31, 2017 at 2:08 PM, Till Rohrmann <[hidden email]> wrote:  

> I would be ok to quickly release 1.3.1 once the the respective PRs have  
> been merged.  
>  
> Just for your information, I'm not yet through with the testing of the type  
> serializer upgrade feature, though.  
>  
> Cheers,  
> Till  
>  
> On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <  
> [hidden email]> wrote:  
>  
> > +1 for releasing now and providing a 1.3.1 release soon.  
> >  
> > > Am 31.05.2017 um 11:02 schrieb Gyula Fóra <[hidden email]>:  
> > >  
> > > Hi All,  
> > >  
> > > I also lean towards getting the release out as soon as possible given  
> > that  
> > > it had been delayed quite a bit and there is no major issue without a  
> > > straightforward workaround (agreeing with Nico and Kostas). I am sure  
> > once  
> > > people will start using the new features we will see more issues that  
> > > should be fixed asap in 1.3.1.  
> > >  
> > > Regarding the critical bug Till had found, we could add a line about it  
> > to  
> > > the release notes so that people don't get blocked by it as there is a  
> > > workaround possible.  
> > >  
> > > Regards,  
> > > Gyula  
> > >  
> > >  
> > > Kostas Kloudas <[hidden email]> ezt írta (időpont: 2017.  
> > máj.  
> > > 31., Sze, 10:53):  
> > >  
> > >> Hi all,  
> > >>  
> > >> I also tend to agree with the argument that says a release should be  
> out  
> > >> as soon as possible, given that 1) it improves usability/functionality  
> > and  
> > >> 2) at a minimum, it does not include new known bugs. The arguments are  
> > >> more or less aligned with Nico’s response on the matter.  
> > >>  
> > >> Focusing on the bug that spiked the current discussion, I agree with  
> > Till  
> > >> that this is alarming, as it passed all previous testing efforts, but  
> I  
> > >> have to  
> > >> add that if nobody so far encountered it, we could release 1.3 now and  
> > fix  
> > >> it in the upcoming 1.3.1.  
> > >>  
> > >> Kostas  
> > >>  
> > >>> On May 31, 2017, at 10:20 AM, Nico Kruber <[hidden email]>  
> > >> wrote:  
> > >>>  
> > >>> IMHO, any release that improves things and does not break anything is  
> > >> worth  
> > >>> releasing and should not be blocked on bugs that it did not cause.  
> > >>> There will always be a next (minor/major) release that may fix this  
> at  
> > a  
> > >> later  
> > >>> time, given that the time between releases is not too high.  
> > >>>  
> > >>> Consider someone waiting for a bugfix/feature that made it into 1.3.0  
> > >> who--if  
> > >>> delayed--would have to wait even longer for "his" bugfix/feature. Any  
> > new  
> > >>> bugfixes (and there will always be more) can wait a few more days or  
> > >> even a few  
> > >>> weeks and may be fixed in 1.3.1 or so.  
> > >>>  
> > >>>  
> > >>> Nico  
> > >>>  
> > >>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:  
> > >>>> - Not sure whether it's a good argument to defer fixing major bugs  
> > >> because  
> > >>>> they have not been introduced with 1.3.0. It's actually alarming  
> that  
> > >> these  
> > >>>> things have not been found earlier given that we test our releases  
> > >>>> thoroughly.  
> > >>>  
> > >>  
> > >>  
> >  
> >  
>  
Reply | Threaded
Open this post in threaded view
|

Re: [RESULT][VOTE] Release Apache Flink 1.3.0 (RC3)

Till Rohrmann
+1 for your suggestions Tzu-Li.

On Tue, Jun 6, 2017 at 9:47 AM, Tzu-Li (Gordon) Tai <[hidden email]>
wrote:

> One suggestion for future major release announcements:
>
> I propose that we add a list of deprecated / breaking API changes in the
> announcement of major releases.
> Although @PublicEnvolving API is not guaranteed to not change across
> releases, it would still be nice that there’s a proper announcement when
> changing or deprecating them.
> Ideally, to avoid collecting the whole list during the release which most
> likely wouldn’t work, we can collect this list on the wiki during the
> development cycle.
>
>
> On 31 May 2017 at 2:22:34 PM, Robert Metzger ([hidden email]) wrote:
>
> Thanks a lot for all your responses on the point Till raised.
> It seems that we have an agreement to release this RC as Flink 1.3.0.
> I'll include a note into the release announcement regarding the state
> descriptor issue.
>
>
> Thanks also for all the release testing and the votes.
>
> +1 votes:
> - Chesnay
> - Robert (binding)
> - jincheng sun
> - Aljoscha (binding)
> - Gordon
> - Greg (binding)
>
> That's 6 votes, out of which 3 are binding.
> Therefore, I'll release RC3 as Flink 1.3.0!
>
>
>
> On Wed, May 31, 2017 at 2:08 PM, Till Rohrmann <[hidden email]>
> wrote:
>
> > I would be ok to quickly release 1.3.1 once the the respective PRs have
> > been merged.
> >
> > Just for your information, I'm not yet through with the testing of the
> type
> > serializer upgrade feature, though.
> >
> > Cheers,
> > Till
> >
> > On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
> > [hidden email]> wrote:
> >
> > > +1 for releasing now and providing a 1.3.1 release soon.
> > >
> > > > Am 31.05.2017 um 11:02 schrieb Gyula Fóra <[hidden email]>:
> > > >
> > > > Hi All,
> > > >
> > > > I also lean towards getting the release out as soon as possible given
> > > that
> > > > it had been delayed quite a bit and there is no major issue without a
> > > > straightforward workaround (agreeing with Nico and Kostas). I am sure
> > > once
> > > > people will start using the new features we will see more issues that
> > > > should be fixed asap in 1.3.1.
> > > >
> > > > Regarding the critical bug Till had found, we could add a line about
> it
> > > to
> > > > the release notes so that people don't get blocked by it as there is
> a
> > > > workaround possible.
> > > >
> > > > Regards,
> > > > Gyula
> > > >
> > > >
> > > > Kostas Kloudas <[hidden email]> ezt írta (időpont:
> 2017.
> > > máj.
> > > > 31., Sze, 10:53):
> > > >
> > > >> Hi all,
> > > >>
> > > >> I also tend to agree with the argument that says a release should be
> > out
> > > >> as soon as possible, given that 1) it improves
> usability/functionality
> > > and
> > > >> 2) at a minimum, it does not include new known bugs. The arguments
> are
> > > >> more or less aligned with Nico’s response on the matter.
> > > >>
> > > >> Focusing on the bug that spiked the current discussion, I agree with
> > > Till
> > > >> that this is alarming, as it passed all previous testing efforts,
> but
> > I
> > > >> have to
> > > >> add that if nobody so far encountered it, we could release 1.3 now
> and
> > > fix
> > > >> it in the upcoming 1.3.1.
> > > >>
> > > >> Kostas
> > > >>
> > > >>> On May 31, 2017, at 10:20 AM, Nico Kruber <[hidden email]>
> > > >> wrote:
> > > >>>
> > > >>> IMHO, any release that improves things and does not break anything
> is
> > > >> worth
> > > >>> releasing and should not be blocked on bugs that it did not cause.
> > > >>> There will always be a next (minor/major) release that may fix this
> > at
> > > a
> > > >> later
> > > >>> time, given that the time between releases is not too high.
> > > >>>
> > > >>> Consider someone waiting for a bugfix/feature that made it into
> 1.3.0
> > > >> who--if
> > > >>> delayed--would have to wait even longer for "his" bugfix/feature.
> Any
> > > new
> > > >>> bugfixes (and there will always be more) can wait a few more days
> or
> > > >> even a few
> > > >>> weeks and may be fixed in 1.3.1 or so.
> > > >>>
> > > >>>
> > > >>> Nico
> > > >>>
> > > >>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
> > > >>>> - Not sure whether it's a good argument to defer fixing major bugs
> > > >> because
> > > >>>> they have not been introduced with 1.3.0. It's actually alarming
> > that
> > > >> these
> > > >>>> things have not been found earlier given that we test our releases
> > > >>>> thoroughly.
> > > >>>
> > > >>
> > > >>
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [RESULT][VOTE] Release Apache Flink 1.3.0 (RC3)

Ted Yu
+1

bq. we can collect this list on the wiki

Or utilize the Release Note field of JIRA for each such change.

On Tue, Jun 6, 2017 at 5:45 AM, Till Rohrmann <[hidden email]> wrote:

> +1 for your suggestions Tzu-Li.
>
> On Tue, Jun 6, 2017 at 9:47 AM, Tzu-Li (Gordon) Tai <[hidden email]>
> wrote:
>
> > One suggestion for future major release announcements:
> >
> > I propose that we add a list of deprecated / breaking API changes in the
> > announcement of major releases.
> > Although @PublicEnvolving API is not guaranteed to not change across
> > releases, it would still be nice that there’s a proper announcement when
> > changing or deprecating them.
> > Ideally, to avoid collecting the whole list during the release which most
> > likely wouldn’t work, we can collect this list on the wiki during the
> > development cycle.
> >
> >
> > On 31 May 2017 at 2:22:34 PM, Robert Metzger ([hidden email])
> wrote:
> >
> > Thanks a lot for all your responses on the point Till raised.
> > It seems that we have an agreement to release this RC as Flink 1.3.0.
> > I'll include a note into the release announcement regarding the state
> > descriptor issue.
> >
> >
> > Thanks also for all the release testing and the votes.
> >
> > +1 votes:
> > - Chesnay
> > - Robert (binding)
> > - jincheng sun
> > - Aljoscha (binding)
> > - Gordon
> > - Greg (binding)
> >
> > That's 6 votes, out of which 3 are binding.
> > Therefore, I'll release RC3 as Flink 1.3.0!
> >
> >
> >
> > On Wed, May 31, 2017 at 2:08 PM, Till Rohrmann <[hidden email]>
> > wrote:
> >
> > > I would be ok to quickly release 1.3.1 once the the respective PRs have
> > > been merged.
> > >
> > > Just for your information, I'm not yet through with the testing of the
> > type
> > > serializer upgrade feature, though.
> > >
> > > Cheers,
> > > Till
> > >
> > > On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
> > > [hidden email]> wrote:
> > >
> > > > +1 for releasing now and providing a 1.3.1 release soon.
> > > >
> > > > > Am 31.05.2017 um 11:02 schrieb Gyula Fóra <[hidden email]>:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > I also lean towards getting the release out as soon as possible
> given
> > > > that
> > > > > it had been delayed quite a bit and there is no major issue
> without a
> > > > > straightforward workaround (agreeing with Nico and Kostas). I am
> sure
> > > > once
> > > > > people will start using the new features we will see more issues
> that
> > > > > should be fixed asap in 1.3.1.
> > > > >
> > > > > Regarding the critical bug Till had found, we could add a line
> about
> > it
> > > > to
> > > > > the release notes so that people don't get blocked by it as there
> is
> > a
> > > > > workaround possible.
> > > > >
> > > > > Regards,
> > > > > Gyula
> > > > >
> > > > >
> > > > > Kostas Kloudas <[hidden email]> ezt írta (időpont:
> > 2017.
> > > > máj.
> > > > > 31., Sze, 10:53):
> > > > >
> > > > >> Hi all,
> > > > >>
> > > > >> I also tend to agree with the argument that says a release should
> be
> > > out
> > > > >> as soon as possible, given that 1) it improves
> > usability/functionality
> > > > and
> > > > >> 2) at a minimum, it does not include new known bugs. The arguments
> > are
> > > > >> more or less aligned with Nico’s response on the matter.
> > > > >>
> > > > >> Focusing on the bug that spiked the current discussion, I agree
> with
> > > > Till
> > > > >> that this is alarming, as it passed all previous testing efforts,
> > but
> > > I
> > > > >> have to
> > > > >> add that if nobody so far encountered it, we could release 1.3 now
> > and
> > > > fix
> > > > >> it in the upcoming 1.3.1.
> > > > >>
> > > > >> Kostas
> > > > >>
> > > > >>> On May 31, 2017, at 10:20 AM, Nico Kruber <
> [hidden email]>
> > > > >> wrote:
> > > > >>>
> > > > >>> IMHO, any release that improves things and does not break
> anything
> > is
> > > > >> worth
> > > > >>> releasing and should not be blocked on bugs that it did not
> cause.
> > > > >>> There will always be a next (minor/major) release that may fix
> this
> > > at
> > > > a
> > > > >> later
> > > > >>> time, given that the time between releases is not too high.
> > > > >>>
> > > > >>> Consider someone waiting for a bugfix/feature that made it into
> > 1.3.0
> > > > >> who--if
> > > > >>> delayed--would have to wait even longer for "his" bugfix/feature.
> > Any
> > > > new
> > > > >>> bugfixes (and there will always be more) can wait a few more days
> > or
> > > > >> even a few
> > > > >>> weeks and may be fixed in 1.3.1 or so.
> > > > >>>
> > > > >>>
> > > > >>> Nico
> > > > >>>
> > > > >>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
> > > > >>>> - Not sure whether it's a good argument to defer fixing major
> bugs
> > > > >> because
> > > > >>>> they have not been introduced with 1.3.0. It's actually alarming
> > > that
> > > > >> these
> > > > >>>> things have not been found earlier given that we test our
> releases
> > > > >>>> thoroughly.
> > > > >>>
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [RESULT][VOTE] Release Apache Flink 1.3.0 (RC3)

Kostas Kloudas
+1 for Gordon’s suggestion.

> On Jun 6, 2017, at 2:52 PM, Ted Yu <[hidden email]> wrote:
>
> +1
>
> bq. we can collect this list on the wiki
>
> Or utilize the Release Note field of JIRA for each such change.
>
> On Tue, Jun 6, 2017 at 5:45 AM, Till Rohrmann <[hidden email]> wrote:
>
>> +1 for your suggestions Tzu-Li.
>>
>> On Tue, Jun 6, 2017 at 9:47 AM, Tzu-Li (Gordon) Tai <[hidden email]>
>> wrote:
>>
>>> One suggestion for future major release announcements:
>>>
>>> I propose that we add a list of deprecated / breaking API changes in the
>>> announcement of major releases.
>>> Although @PublicEnvolving API is not guaranteed to not change across
>>> releases, it would still be nice that there’s a proper announcement when
>>> changing or deprecating them.
>>> Ideally, to avoid collecting the whole list during the release which most
>>> likely wouldn’t work, we can collect this list on the wiki during the
>>> development cycle.
>>>
>>>
>>> On 31 May 2017 at 2:22:34 PM, Robert Metzger ([hidden email])
>> wrote:
>>>
>>> Thanks a lot for all your responses on the point Till raised.
>>> It seems that we have an agreement to release this RC as Flink 1.3.0.
>>> I'll include a note into the release announcement regarding the state
>>> descriptor issue.
>>>
>>>
>>> Thanks also for all the release testing and the votes.
>>>
>>> +1 votes:
>>> - Chesnay
>>> - Robert (binding)
>>> - jincheng sun
>>> - Aljoscha (binding)
>>> - Gordon
>>> - Greg (binding)
>>>
>>> That's 6 votes, out of which 3 are binding.
>>> Therefore, I'll release RC3 as Flink 1.3.0!
>>>
>>>
>>>
>>> On Wed, May 31, 2017 at 2:08 PM, Till Rohrmann <[hidden email]>
>>> wrote:
>>>
>>>> I would be ok to quickly release 1.3.1 once the the respective PRs have
>>>> been merged.
>>>>
>>>> Just for your information, I'm not yet through with the testing of the
>>> type
>>>> serializer upgrade feature, though.
>>>>
>>>> Cheers,
>>>> Till
>>>>
>>>> On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
>>>> [hidden email]> wrote:
>>>>
>>>>> +1 for releasing now and providing a 1.3.1 release soon.
>>>>>
>>>>>> Am 31.05.2017 um 11:02 schrieb Gyula Fóra <[hidden email]>:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I also lean towards getting the release out as soon as possible
>> given
>>>>> that
>>>>>> it had been delayed quite a bit and there is no major issue
>> without a
>>>>>> straightforward workaround (agreeing with Nico and Kostas). I am
>> sure
>>>>> once
>>>>>> people will start using the new features we will see more issues
>> that
>>>>>> should be fixed asap in 1.3.1.
>>>>>>
>>>>>> Regarding the critical bug Till had found, we could add a line
>> about
>>> it
>>>>> to
>>>>>> the release notes so that people don't get blocked by it as there
>> is
>>> a
>>>>>> workaround possible.
>>>>>>
>>>>>> Regards,
>>>>>> Gyula
>>>>>>
>>>>>>
>>>>>> Kostas Kloudas <[hidden email]> ezt írta (időpont:
>>> 2017.
>>>>> máj.
>>>>>> 31., Sze, 10:53):
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I also tend to agree with the argument that says a release should
>> be
>>>> out
>>>>>>> as soon as possible, given that 1) it improves
>>> usability/functionality
>>>>> and
>>>>>>> 2) at a minimum, it does not include new known bugs. The arguments
>>> are
>>>>>>> more or less aligned with Nico’s response on the matter.
>>>>>>>
>>>>>>> Focusing on the bug that spiked the current discussion, I agree
>> with
>>>>> Till
>>>>>>> that this is alarming, as it passed all previous testing efforts,
>>> but
>>>> I
>>>>>>> have to
>>>>>>> add that if nobody so far encountered it, we could release 1.3 now
>>> and
>>>>> fix
>>>>>>> it in the upcoming 1.3.1.
>>>>>>>
>>>>>>> Kostas
>>>>>>>
>>>>>>>> On May 31, 2017, at 10:20 AM, Nico Kruber <
>> [hidden email]>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> IMHO, any release that improves things and does not break
>> anything
>>> is
>>>>>>> worth
>>>>>>>> releasing and should not be blocked on bugs that it did not
>> cause.
>>>>>>>> There will always be a next (minor/major) release that may fix
>> this
>>>> at
>>>>> a
>>>>>>> later
>>>>>>>> time, given that the time between releases is not too high.
>>>>>>>>
>>>>>>>> Consider someone waiting for a bugfix/feature that made it into
>>> 1.3.0
>>>>>>> who--if
>>>>>>>> delayed--would have to wait even longer for "his" bugfix/feature.
>>> Any
>>>>> new
>>>>>>>> bugfixes (and there will always be more) can wait a few more days
>>> or
>>>>>>> even a few
>>>>>>>> weeks and may be fixed in 1.3.1 or so.
>>>>>>>>
>>>>>>>>
>>>>>>>> Nico
>>>>>>>>
>>>>>>>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
>>>>>>>>> - Not sure whether it's a good argument to defer fixing major
>> bugs
>>>>>>> because
>>>>>>>>> they have not been introduced with 1.3.0. It's actually alarming
>>>> that
>>>>>>> these
>>>>>>>>> things have not been found earlier given that we test our
>> releases
>>>>>>>>> thoroughly.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>