Bumping this thread again.
I think it would help Flink development a lot to drop 1.1.x savepoint
format compatibility in 1.4.0. That means NOT dropping API compatibility,
only not further supporting the old savepoint format version.
I'll start a poll on the users list.
On Fri, Jun 30, 2017 at 7:
@Sebastian: I am not sure Apache has really guidelines there. So far, I
thought projects establish their own policies.
The compatibility questions here is also one of APIs (code), but of
savepoint forwarding, which is a but different, I think. For example 1.0
and 1.1 were not compatible there, the
I haven't closely followed the discussion so far, but isn't it Apache
policy that major versions should stay backwards compatible to all previous
releases with the same major version?
-s
2017-06-28 12:26 GMT+02:00 Kostas Kloudas :
> I agree that 1.1 compatibility is the most important “pain poin
I agree that 1.1 compatibility is the most important “pain point", as
compatibility with the rest of the versions follows a more “systematic”
approach.
I think that discarding compatibility with 1.1 will clear some parts
of the codebase significantly.
Kostas
> On Jun 27, 2017, at 6:03 PM, Ste
I think that this discussion is probably motivated especially by the
"legacy state" handling of Flink 1.1.
The biggest gain in codebase and productivity would be won only by dropping
1.1 compatibility in Flink 1.4.
My gut feeling is that this is reasonable. We support two versions back,
which mean
For many parts of the code, I would agree with Aljoscha. However, I can also
see notable exceptions, such as maintaining support for the legacy state from
Flink <=1.1. For example, I think dropping support for this can simplify new
developments such as fast local recovery or state replication qu
Normally, I’m the first one to suggest removing everything that is not
absolutely necessary in order to have a clean code base. On this issue, though,
I think we should support restoring from old Savepoints as far back as possible
if it does not make the code completely unmaintainable. Some user
bq. about having LTS versions once a year
+1 to the above.
There may be various reasons users don't want to upgrade (after new
releases come out). We should give such users enough flexibility on the
upgrade path.
Cheers
On Wed, May 24, 2017 at 8:39 AM, Kostas Kloudas wrote:
> Hi all,
>
> For
Hi all,
For the proposal of having a third party tool, I agree with Ted. Maintaining
it is a big and far from trivial effort.
Now for the window of backwards compatibility, I would argue that even if
for some users 4 months (1 release) is not enough to bump their Flink version,
the proposed po
For #2, it is difficult to achieve:
a. maintaining savepoint migration is non-trivial and should be reviewed by
domain experts
b. how to certify such third-party tool
Cheers
On Mon, May 22, 2017 at 3:04 AM, 施晓罡 wrote:
> Hi all,
>
> Currently, we work a lot in the maintenance of compatibility.
I can’t find when the time-based maintenance schedule switched from “6 months”
to “2 concurrent versions” (which has not yet made it into the website [0]). Is
it correct to assume that most users are waiting until the first bug fix
release or later to upgrade? That only leaves a narrow window of
Hi all,
Currently, we work a lot in the maintenance of compatibility.
There exist much code in runtime to support the migration of savepoints (most
of which are deprecated), making it hard to focus on the current implementation.
When more versions are released, much more efforts will be needed
Hi Kostas,
Thanks for bringing this up!
I think it is reasonable to keep this coherent with our timely-based release
model guarantees.
With the timely-based release model, there is a guarantee that the current
latest major version and the previous one is supported.
For example, upon releasing 1
Hi Chesnay,
I believe that for APIs we already have a pretty clear policy with the
annotations.
I was referring to savepoints and state related backwards compatibility.
> On May 20, 2017, at 7:20 PM, Chesnay Schepler wrote:
>
> I think it would be a good to clarify what kind of backwards-comp
I think it would be a good to clarify what kind of
backwards-compatibilitiy we're talking about here. As in are we talking
about APIs or savepoints?
On 20.05.2017 19:09, Kostas Kloudas wrote:
Hi all,
As we are getting closer to releasing Flink-1.3, I would like to open a
discussion
on how fa
Hi all,
As we are getting closer to releasing Flink-1.3, I would like to open a
discussion
on how far back we provide backwards compatibility for.
The reason for opening the discussion is that i) for the users and for the
adoption of the project, it is good to have an explicitely stated policy
16 matches
Mail list logo
