0.7.1 maintenance release

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

0.7.1 maintenance release

Ufuk Celebi-2
Hey all,

I would like to discuss your view on having a 0.7.1 maintenance release.

Although there are no commits in the respective branches (except
documentation updates), I think we already have a set of issues/fixes,
which would be beneficial to have in a release.

I vote to start collecting/cherry-picking issues to the respective branch.

– Ufuk
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

Márton Balassi
+1 There are a couple of streaming bugfix commits that I'd like to push
there.

I would also like to volunteer as release manager.

Best,

Marton

On Mon, Nov 24, 2014 at 10:39 AM, Ufuk Celebi <[hidden email]> wrote:

> Hey all,
>
> I would like to discuss your view on having a 0.7.1 maintenance release.
>
> Although there are no commits in the respective branches (except
> documentation updates), I think we already have a set of issues/fixes,
> which would be beneficial to have in a release.
>
> I vote to start collecting/cherry-picking issues to the respective branch.
>
> – Ufuk
>
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

Robert Metzger
+1 for Marton as a release manager. Let me know if you need any help.

I'm trying to find some time today to collect a list of commits I'd like to
include.

On Mon, Nov 24, 2014 at 10:51 AM, Márton Balassi <[hidden email]>
wrote:

> +1 There are a couple of streaming bugfix commits that I'd like to push
> there.
>
> I would also like to volunteer as release manager.
>
> Best,
>
> Marton
>
> On Mon, Nov 24, 2014 at 10:39 AM, Ufuk Celebi <[hidden email]> wrote:
>
> > Hey all,
> >
> > I would like to discuss your view on having a 0.7.1 maintenance release.
> >
> > Although there are no commits in the respective branches (except
> > documentation updates), I think we already have a set of issues/fixes,
> > which would be beneficial to have in a release.
> >
> > I vote to start collecting/cherry-picking issues to the respective
> branch.
> >
> > – Ufuk
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

Stephan Ewen
+1

I can help assembling a list of commits to cherry-pick from 0.8-SNAPSHOT to
the 0.7.1 release branch tomorrow or on Wednesday.

Stephan


On Mon, Nov 24, 2014 at 11:37 AM, Robert Metzger <[hidden email]>
wrote:

> +1 for Marton as a release manager. Let me know if you need any help.
>
> I'm trying to find some time today to collect a list of commits I'd like to
> include.
>
> On Mon, Nov 24, 2014 at 10:51 AM, Márton Balassi <[hidden email]
> >
> wrote:
>
> > +1 There are a couple of streaming bugfix commits that I'd like to push
> > there.
> >
> > I would also like to volunteer as release manager.
> >
> > Best,
> >
> > Marton
> >
> > On Mon, Nov 24, 2014 at 10:39 AM, Ufuk Celebi <[hidden email]> wrote:
> >
> > > Hey all,
> > >
> > > I would like to discuss your view on having a 0.7.1 maintenance
> release.
> > >
> > > Although there are no commits in the respective branches (except
> > > documentation updates), I think we already have a set of issues/fixes,
> > > which would be beneficial to have in a release.
> > >
> > > I vote to start collecting/cherry-picking issues to the respective
> > branch.
> > >
> > > – Ufuk
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

Ufuk Celebi-2
@Marton: +1 :)

On Mon, Nov 24, 2014 at 1:57 PM, Stephan Ewen <[hidden email]> wrote:

> +1
>
> I can help assembling a list of commits to cherry-pick from 0.8-SNAPSHOT to
> the 0.7.1 release branch tomorrow or on Wednesday.
>
> Stephan
>
>
> On Mon, Nov 24, 2014 at 11:37 AM, Robert Metzger <[hidden email]>
> wrote:
>
> > +1 for Marton as a release manager. Let me know if you need any help.
> >
> > I'm trying to find some time today to collect a list of commits I'd like
> to
> > include.
> >
> > On Mon, Nov 24, 2014 at 10:51 AM, Márton Balassi <
> [hidden email]
> > >
> > wrote:
> >
> > > +1 There are a couple of streaming bugfix commits that I'd like to push
> > > there.
> > >
> > > I would also like to volunteer as release manager.
> > >
> > > Best,
> > >
> > > Marton
> > >
> > > On Mon, Nov 24, 2014 at 10:39 AM, Ufuk Celebi <[hidden email]> wrote:
> > >
> > > > Hey all,
> > > >
> > > > I would like to discuss your view on having a 0.7.1 maintenance
> > release.
> > > >
> > > > Although there are no commits in the respective branches (except
> > > > documentation updates), I think we already have a set of
> issues/fixes,
> > > > which would be beneficial to have in a release.
> > > >
> > > > I vote to start collecting/cherry-picking issues to the respective
> > > branch.
> > > >
> > > > – Ufuk
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

Fabian Hueske
Thanks Marton for volunteering!

2014-11-24 15:18 GMT+01:00 Ufuk Celebi <[hidden email]>:

> @Marton: +1 :)
>
> On Mon, Nov 24, 2014 at 1:57 PM, Stephan Ewen <[hidden email]> wrote:
>
> > +1
> >
> > I can help assembling a list of commits to cherry-pick from 0.8-SNAPSHOT
> to
> > the 0.7.1 release branch tomorrow or on Wednesday.
> >
> > Stephan
> >
> >
> > On Mon, Nov 24, 2014 at 11:37 AM, Robert Metzger <[hidden email]>
> > wrote:
> >
> > > +1 for Marton as a release manager. Let me know if you need any help.
> > >
> > > I'm trying to find some time today to collect a list of commits I'd
> like
> > to
> > > include.
> > >
> > > On Mon, Nov 24, 2014 at 10:51 AM, Márton Balassi <
> > [hidden email]
> > > >
> > > wrote:
> > >
> > > > +1 There are a couple of streaming bugfix commits that I'd like to
> push
> > > > there.
> > > >
> > > > I would also like to volunteer as release manager.
> > > >
> > > > Best,
> > > >
> > > > Marton
> > > >
> > > > On Mon, Nov 24, 2014 at 10:39 AM, Ufuk Celebi <[hidden email]>
> wrote:
> > > >
> > > > > Hey all,
> > > > >
> > > > > I would like to discuss your view on having a 0.7.1 maintenance
> > > release.
> > > > >
> > > > > Although there are no commits in the respective branches (except
> > > > > documentation updates), I think we already have a set of
> > issues/fixes,
> > > > > which would be beneficial to have in a release.
> > > > >
> > > > > I vote to start collecting/cherry-picking issues to the respective
> > > > branch.
> > > > >
> > > > > – Ufuk
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

Henry Saputra
In reply to this post by Márton Balassi
+1

Would be good to have different RM to give feedback how existing
process working.

Thanks for volunteering.

- Henry

On Mon, Nov 24, 2014 at 1:51 AM, Márton Balassi
<[hidden email]> wrote:

> +1 There are a couple of streaming bugfix commits that I'd like to push
> there.
>
> I would also like to volunteer as release manager.
>
> Best,
>
> Marton
>
> On Mon, Nov 24, 2014 at 10:39 AM, Ufuk Celebi <[hidden email]> wrote:
>
>> Hey all,
>>
>> I would like to discuss your view on having a 0.7.1 maintenance release.
>>
>> Although there are no commits in the respective branches (except
>> documentation updates), I think we already have a set of issues/fixes,
>> which would be beneficial to have in a release.
>>
>> I vote to start collecting/cherry-picking issues to the respective branch.
>>
>> – Ufuk
>>
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

Till Rohrmann
+1 for Marton and the maintenance release.

On Mon, Nov 24, 2014 at 6:52 PM, Henry Saputra <[hidden email]> wrote:

> +1
>
> Would be good to have different RM to give feedback how existing
> process working.
>
> Thanks for volunteering.
>
> - Henry
>
> On Mon, Nov 24, 2014 at 1:51 AM, Márton Balassi
> <[hidden email]> wrote:
>> +1 There are a couple of streaming bugfix commits that I'd like to push
>> there.
>>
>> I would also like to volunteer as release manager.
>>
>> Best,
>>
>> Marton
>>
>> On Mon, Nov 24, 2014 at 10:39 AM, Ufuk Celebi <[hidden email]> wrote:
>>
>>> Hey all,
>>>
>>> I would like to discuss your view on having a 0.7.1 maintenance release.
>>>
>>> Although there are no commits in the respective branches (except
>>> documentation updates), I think we already have a set of issues/fixes,
>>> which would be beneficial to have in a release.
>>>
>>> I vote to start collecting/cherry-picking issues to the respective branch.
>>>
>>> – Ufuk
>>>
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

Kostas Tzoumas-2
+1, thanks Marton!

On Mon, Nov 24, 2014 at 11:51 PM, Till Rohrmann <[hidden email]>
wrote:

> +1 for Marton and the maintenance release.
>
> On Mon, Nov 24, 2014 at 6:52 PM, Henry Saputra <[hidden email]>
> wrote:
> > +1
> >
> > Would be good to have different RM to give feedback how existing
> > process working.
> >
> > Thanks for volunteering.
> >
> > - Henry
> >
> > On Mon, Nov 24, 2014 at 1:51 AM, Márton Balassi
> > <[hidden email]> wrote:
> >> +1 There are a couple of streaming bugfix commits that I'd like to push
> >> there.
> >>
> >> I would also like to volunteer as release manager.
> >>
> >> Best,
> >>
> >> Marton
> >>
> >> On Mon, Nov 24, 2014 at 10:39 AM, Ufuk Celebi <[hidden email]> wrote:
> >>
> >>> Hey all,
> >>>
> >>> I would like to discuss your view on having a 0.7.1 maintenance
> release.
> >>>
> >>> Although there are no commits in the respective branches (except
> >>> documentation updates), I think we already have a set of issues/fixes,
> >>> which would be beneficial to have in a release.
> >>>
> >>> I vote to start collecting/cherry-picking issues to the respective
> branch.
> >>>
> >>> – Ufuk
> >>>
>
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

Robert Metzger
I looked through the commits since the last release and there is a huge
amount of improvements we could include.
I was thinking about limiting the commits for the bugfix release to a
absolute minimum. Only those issues users complained about or cause the
system not to work at all should be included in my opinion.
I would not include issues that cause bad performance, fix testcases or
code-style. I would rather prefer to aim for a 0.8 release soon (maybe a
Christmas or new year release ;) )

These are my candidates:

[FLINK-1154] Quickfix to kill TaskManagers in YARN mode.
 e46d14b4c7507b23f2c80e0d893cfff6f6c49bae
[runtime] CaseClassSerializer correctly treated as stateful
f66892d46d80d453a55fd0ae14095ee06275a55d
[runtime] Quick fix for error with unsupported ship strategy
87497b7235088b2220aa356a14cbff9d43d5dffb
[FLINK-1265] Fix user classloader bug for registerInputOutput() method
4a74f3281bd04ed76b911d2038ea8e3d9c0b7963
[FLINK-1252] Add support for serializing Date and Enums in the Java API
591f16dd8f80cc2a5b2fdc6654c3c2d625119faa
[FLINK-1251] Enums are now handled properly by the collection input format
8081ddc530e6c7b720da09ac0fca2095d70fdd36
[FLINK-1254] [compiler] Fix compiler bug for pipeline breaker placement
ce822bf7f5ec80df5d5a749b1439320af3fb8b18
[streaming] StreamExecutionEnvironment rework + user class loader fix for
cluster deployment 6867f9b93ec1ad9a627450c4fbd0b5ff98ef6148
[FLINK-1235] Compiler accepts iterations referenced from the static path of
other iterations 21b1b975ccb50e1831172894bde96c6d3269dc57



On Tue, Nov 25, 2014 at 3:32 PM, Kostas Tzoumas <[hidden email]> wrote:

> +1, thanks Marton!
>
> On Mon, Nov 24, 2014 at 11:51 PM, Till Rohrmann <[hidden email]>
> wrote:
>
> > +1 for Marton and the maintenance release.
> >
> > On Mon, Nov 24, 2014 at 6:52 PM, Henry Saputra <[hidden email]>
> > wrote:
> > > +1
> > >
> > > Would be good to have different RM to give feedback how existing
> > > process working.
> > >
> > > Thanks for volunteering.
> > >
> > > - Henry
> > >
> > > On Mon, Nov 24, 2014 at 1:51 AM, Márton Balassi
> > > <[hidden email]> wrote:
> > >> +1 There are a couple of streaming bugfix commits that I'd like to
> push
> > >> there.
> > >>
> > >> I would also like to volunteer as release manager.
> > >>
> > >> Best,
> > >>
> > >> Marton
> > >>
> > >> On Mon, Nov 24, 2014 at 10:39 AM, Ufuk Celebi <[hidden email]> wrote:
> > >>
> > >>> Hey all,
> > >>>
> > >>> I would like to discuss your view on having a 0.7.1 maintenance
> > release.
> > >>>
> > >>> Although there are no commits in the respective branches (except
> > >>> documentation updates), I think we already have a set of
> issues/fixes,
> > >>> which would be beneficial to have in a release.
> > >>>
> > >>> I vote to start collecting/cherry-picking issues to the respective
> > branch.
> > >>>
> > >>> – Ufuk
> > >>>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

Márton Balassi
+1 for sticking to the absolute minimum number of bugfix commits
+1 for pushing out 0.8.0 soon

As for streaming including only the one commit you mentioned [1] seems
sufficient.

[1] [streaming] StreamExecutionEnvironment rework + user class loader fix
for
cluster deployment 6867f9b93ec1ad9a627450c4fbd0b5ff98ef6148

On Mon, Dec 1, 2014 at 12:15 PM, Robert Metzger <[hidden email]> wrote:

> I looked through the commits since the last release and there is a huge
> amount of improvements we could include.
> I was thinking about limiting the commits for the bugfix release to a
> absolute minimum. Only those issues users complained about or cause the
> system not to work at all should be included in my opinion.
> I would not include issues that cause bad performance, fix testcases or
> code-style. I would rather prefer to aim for a 0.8 release soon (maybe a
> Christmas or new year release ;) )
>
> These are my candidates:
>
> [FLINK-1154] Quickfix to kill TaskManagers in YARN mode.
>  e46d14b4c7507b23f2c80e0d893cfff6f6c49bae
> [runtime] CaseClassSerializer correctly treated as stateful
> f66892d46d80d453a55fd0ae14095ee06275a55d
> [runtime] Quick fix for error with unsupported ship strategy
> 87497b7235088b2220aa356a14cbff9d43d5dffb
> [FLINK-1265] Fix user classloader bug for registerInputOutput() method
> 4a74f3281bd04ed76b911d2038ea8e3d9c0b7963
> [FLINK-1252] Add support for serializing Date and Enums in the Java API
> 591f16dd8f80cc2a5b2fdc6654c3c2d625119faa
> [FLINK-1251] Enums are now handled properly by the collection input format
> 8081ddc530e6c7b720da09ac0fca2095d70fdd36
> [FLINK-1254] [compiler] Fix compiler bug for pipeline breaker placement
> ce822bf7f5ec80df5d5a749b1439320af3fb8b18
> [streaming] StreamExecutionEnvironment rework + user class loader fix for
> cluster deployment 6867f9b93ec1ad9a627450c4fbd0b5ff98ef6148
> [FLINK-1235] Compiler accepts iterations referenced from the static path of
> other iterations 21b1b975ccb50e1831172894bde96c6d3269dc57
>
>
>
> On Tue, Nov 25, 2014 at 3:32 PM, Kostas Tzoumas <[hidden email]>
> wrote:
>
> > +1, thanks Marton!
> >
> > On Mon, Nov 24, 2014 at 11:51 PM, Till Rohrmann <[hidden email]>
> > wrote:
> >
> > > +1 for Marton and the maintenance release.
> > >
> > > On Mon, Nov 24, 2014 at 6:52 PM, Henry Saputra <
> [hidden email]>
> > > wrote:
> > > > +1
> > > >
> > > > Would be good to have different RM to give feedback how existing
> > > > process working.
> > > >
> > > > Thanks for volunteering.
> > > >
> > > > - Henry
> > > >
> > > > On Mon, Nov 24, 2014 at 1:51 AM, Márton Balassi
> > > > <[hidden email]> wrote:
> > > >> +1 There are a couple of streaming bugfix commits that I'd like to
> > push
> > > >> there.
> > > >>
> > > >> I would also like to volunteer as release manager.
> > > >>
> > > >> Best,
> > > >>
> > > >> Marton
> > > >>
> > > >> On Mon, Nov 24, 2014 at 10:39 AM, Ufuk Celebi <[hidden email]>
> wrote:
> > > >>
> > > >>> Hey all,
> > > >>>
> > > >>> I would like to discuss your view on having a 0.7.1 maintenance
> > > release.
> > > >>>
> > > >>> Although there are no commits in the respective branches (except
> > > >>> documentation updates), I think we already have a set of
> > issues/fixes,
> > > >>> which would be beneficial to have in a release.
> > > >>>
> > > >>> I vote to start collecting/cherry-picking issues to the respective
> > > branch.
> > > >>>
> > > >>> – Ufuk
> > > >>>
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

Ufuk Celebi-2
In reply to this post by Robert Metzger
On Mon, Dec 1, 2014 at 12:15 PM, Robert Metzger <[hidden email]> wrote:

> I would not include issues that cause bad performance, fix testcases or
> code-style. I would rather prefer to aim for a 0.8 release soon (maybe a
> Christmas or new year release ;) )
>


Is there a performance-critical commit, which would be *more* work to back
port than the other commits? If not, I don't see any reason to exclude them.
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

till.rohrmann
If we include the commit

[runtime] CaseClassSerializer correctly treated as stateful
f66892d46d80d453a55fd0ae14095ee06275a55d

then we also have to include

3d242fd7aea6add18465d628a258be11def2d0af

because the ScalaCsvInputFormat using the CaseClassSerializer won't work
properly anymore with the CaseClassSerializer set to be stateful.


On Mon, Dec 1, 2014 at 12:50 PM, Ufuk Celebi <[hidden email]> wrote:

> On Mon, Dec 1, 2014 at 12:15 PM, Robert Metzger <[hidden email]>
> wrote:
>
> > I would not include issues that cause bad performance, fix testcases or
> > code-style. I would rather prefer to aim for a 0.8 release soon (maybe a
> > Christmas or new year release ;) )
> >
>
>
> Is there a performance-critical commit, which would be *more* work to back
> port than the other commits? If not, I don't see any reason to exclude
> them.
>
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

Stephan Ewen
Would it be simpler to list what we not include? I think most of the stuff
added since then is fixes, not fundamental features. I would include almost
all of it, also the closure cleaner, the type fixes, ...

On Mon, Dec 1, 2014 at 1:59 PM, Till Rohrmann <[hidden email]>
wrote:

> If we include the commit
>
> [runtime] CaseClassSerializer correctly treated as stateful
> f66892d46d80d453a55fd0ae14095ee06275a55d
>
> then we also have to include
>
> 3d242fd7aea6add18465d628a258be11def2d0af
>
> because the ScalaCsvInputFormat using the CaseClassSerializer won't work
> properly anymore with the CaseClassSerializer set to be stateful.
>
>
> On Mon, Dec 1, 2014 at 12:50 PM, Ufuk Celebi <[hidden email]> wrote:
>
> > On Mon, Dec 1, 2014 at 12:15 PM, Robert Metzger <[hidden email]>
> > wrote:
> >
> > > I would not include issues that cause bad performance, fix testcases or
> > > code-style. I would rather prefer to aim for a 0.8 release soon (maybe
> a
> > > Christmas or new year release ;) )
> > >
> >
> >
> > Is there a performance-critical commit, which would be *more* work to
> back
> > port than the other commits? If not, I don't see any reason to exclude
> > them.
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

Robert Metzger
If the bugfix release is going to include almost all commits of the current
0.8-SNAPSHOT version, we should consider releasing it as Flink 0.8.0.

The amount of required work for making a bugfix or a major release is
basically the same.

On Mon, Dec 1, 2014 at 3:57 PM, Stephan Ewen <[hidden email]> wrote:

> Would it be simpler to list what we not include? I think most of the stuff
> added since then is fixes, not fundamental features. I would include almost
> all of it, also the closure cleaner, the type fixes, ...
>
> On Mon, Dec 1, 2014 at 1:59 PM, Till Rohrmann <[hidden email]>
> wrote:
>
> > If we include the commit
> >
> > [runtime] CaseClassSerializer correctly treated as stateful
> > f66892d46d80d453a55fd0ae14095ee06275a55d
> >
> > then we also have to include
> >
> > 3d242fd7aea6add18465d628a258be11def2d0af
> >
> > because the ScalaCsvInputFormat using the CaseClassSerializer won't work
> > properly anymore with the CaseClassSerializer set to be stateful.
> >
> >
> > On Mon, Dec 1, 2014 at 12:50 PM, Ufuk Celebi <[hidden email]> wrote:
> >
> > > On Mon, Dec 1, 2014 at 12:15 PM, Robert Metzger <[hidden email]>
> > > wrote:
> > >
> > > > I would not include issues that cause bad performance, fix testcases
> or
> > > > code-style. I would rather prefer to aim for a 0.8 release soon
> (maybe
> > a
> > > > Christmas or new year release ;) )
> > > >
> > >
> > >
> > > Is there a performance-critical commit, which would be *more* work to
> > back
> > > port than the other commits? If not, I don't see any reason to exclude
> > > them.
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

Ufuk Celebi-2
On Mon, Dec 1, 2014 at 4:45 PM, Robert Metzger <[hidden email]> wrote:

> If the bugfix release is going to include almost all commits of the current
> 0.8-SNAPSHOT version, we should consider releasing it as Flink 0.8.0.
>

I think it is reasonable to have new major versions for new major features.
Since we don't have any new major features, we should stick to 0.7.1.


The amount of required work for making a bugfix or a major release is
> basically the same.
>

I would actually say that a bugfix release requires more work. ;-)
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

Fabian Hueske
I agree with Ufuk.

+1 for putting this out as a minor release (0.7.1).

2014-12-01 17:27 GMT+01:00 Ufuk Celebi <[hidden email]>:

> On Mon, Dec 1, 2014 at 4:45 PM, Robert Metzger <[hidden email]>
> wrote:
>
> > If the bugfix release is going to include almost all commits of the
> current
> > 0.8-SNAPSHOT version, we should consider releasing it as Flink 0.8.0.
> >
>
> I think it is reasonable to have new major versions for new major features.
> Since we don't have any new major features, we should stick to 0.7.1.
>
>
> The amount of required work for making a bugfix or a major release is
> > basically the same.
> >
>
> I would actually say that a bugfix release requires more work. ;-)
>
Reply | Threaded
Open this post in threaded view
|

Re: 0.7.1 maintenance release

Márton Balassi
It is a bit unclear for me how to proceed with this issue. If I understand
it correctly the votes were more for a smaller bugfix release than for
adding most of the code since 0.7.0, but correct me if I'm wrong.

Robert and Till assembled the following list fot commits to be included
then:

[FLINK-1154] Quickfix to kill TaskManagers in YARN mode.
 e46d14b4c7507b23f2c80e0d893cfff6f6c49bae
[runtime] CaseClassSerializer correctly treated as stateful
f66892d46d80d453a55fd0ae14095ee06275a55d
[runtime] Quick fix for error with unsupported ship strategy
87497b7235088b2220aa356a14cbff9d43d5dffb
[FLINK-1265] Fix user classloader bug for registerInputOutput() method
4a74f3281bd04ed76b911d2038ea8e3d9c0b7963
[FLINK-1252] Add support for serializing Date and Enums in the Java API
591f16dd8f80cc2a5b2fdc6654c3c2d625119faa
[FLINK-1251] Enums are now handled properly by the collection input format
8081ddc530e6c7b720da09ac0fca2095d70fdd36
[FLINK-1254] [compiler] Fix compiler bug for pipeline breaker placement
ce822bf7f5ec80df5d5a749b1439320af3fb8b18
[streaming] StreamExecutionEnvironment rework + user class loader fix for
cluster deployment 6867f9b93ec1ad9a627450c4fbd0b5ff98ef6148
[FLINK-1235] Compiler accepts iterations referenced from the static path of
other iterations 21b1b975ccb50e1831172894bde96c6d3269dc57
Removed TypeSerializerFactory from ScalaCsvInputFormat. The TypeSerializer
is now serialized directly. 3d242fd7aea6add18465d628a258be11def2d0af

And of course the doc fixes that are alredy on the release-0.7 branch. I'd
like to push these to the release-0.7 branch and fork release-0.7.1 from it
then.

Cheers,

Marton


On Mon, Dec 1, 2014 at 5:35 PM, Fabian Hueske <[hidden email]> wrote:

> I agree with Ufuk.
>
> +1 for putting this out as a minor release (0.7.1).
>
> 2014-12-01 17:27 GMT+01:00 Ufuk Celebi <[hidden email]>:
>
> > On Mon, Dec 1, 2014 at 4:45 PM, Robert Metzger <[hidden email]>
> > wrote:
> >
> > > If the bugfix release is going to include almost all commits of the
> > current
> > > 0.8-SNAPSHOT version, we should consider releasing it as Flink 0.8.0.
> > >
> >
> > I think it is reasonable to have new major versions for new major
> features.
> > Since we don't have any new major features, we should stick to 0.7.1.
> >
> >
> > The amount of required work for making a bugfix or a major release is
> > > basically the same.
> > >
> >
> > I would actually say that a bugfix release requires more work. ;-)
> >
>