OK then.
We've already discussed that DLTK 5.6 will switch to Java 8 [1]. So
we can try this approach.
Who wants to prepare the patch? :)
[1] https://dev.eclipse.org/mhonarc/lists/dltk-dev/msg02552.html
Kaloyan
On 08/24/2016 05:31 PM, Dawid Pakuła
wrote:
Hi,
Yes,
Java 8. Neon require it in general so this shouldn’t be a
problem.
But
I don’t know how default methods affect Eclipse API Policy. For
me as long as adopter don’t have to modify code to by compatible
with next version, it’s not api break.
I am not familiar with them... Are they introduced in Java
8? Or in
an earlier version.
Kaloyan
On 08/24/2016 05:25 PM, Dawid
Pakuła
wrote:
Hi,
how
about default method in interface?
default
public int
getFlags() {
return 0;
}
Hi Thierry,
This change was introduced by a patch of yours.
Could you re-work it to be backward compatible
for Neon.1
RC2?
I believe this can be achieved by introducing
the getFlags() method
in a new interface IParameter2 that extends the
old (and untouched)
IParameter interface. This way we will have the
old IParameter
interface untouched for those need the backward
compatibility and
the new IParameter2 for those who need the new
functionality.
Kaloyan
On 08/23/2016
06:15 PM, Simon
Bernard wrote:
Hi there is an API break in
DLTK 5.6.
I talked about the add of getFlags() on
IParameter.
https://git.eclipse.org/c/dltk/org.eclipse.dltk.core.git/commit/?id=b0517331fc42d2c7029477fc55611316da1750c2
Could we avoid this API break for both Oxygen
and Neon.
(In all case for Neon this seems to me
mandatory to not break the
API)
Thx
Simon
Le 09/08/2016
à 15:59, Kaloyan
Raev a écrit :
Hi,
thanks!
After DLTK declare I’ll promote PDT
builds.
Hi Dawid,
Of course, DLTK 5.6 will
be part of Neon.1.
The Checkpoint was
mandatory only for *new*
projects in
the release train.
Tomorrow is the Oxygen M1
+2 date. I will declare
the DLTK 5.6 M1 milestone. I
will contribute it to both the
Oxygen and Neon.1 simrel
builds.
Two weeks later is the
Neon.1 RC1 +2 date. I will
declare
the DLTK 5.6 RC1 milestone and
contribute it to the Neon.1
simrel
build.
The same can be done for
PDT on the respective +3
dates.
Sounds good?
Kaloyan
Hi,
I
hope DLTK 5.6 will be part of
Neon.1, without it we cannot
promote PDT 4.1 to Neon.1
simrel.
We
are behind checkpoint, next
Neon.1 build will be
RC1.
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
To change your delivery options,
retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/dltk-dev
|