[cc: gwt-contrib, please follow-up there]
On Tue, Oct 8, 2013 at 10:06 AM, Artur Signell wrote:
> On Oct 8, 2013, at 4:59 AM, Matthew Dempsky wrote:
>
> On Mon, Oct 7, 2013 at 1:17 AM, Joonas Lehtinen wrote:
>
>> Furthermore we should decide if GWT 3.0 supports Java 6+ or Java 7+ or
>> Java 8
As long as we don't use Java8 specific features in non-supersourced code,
we can get away with running on other JREs. So for example, the public
interfaces and internal implementations of gwt-user APIs could probably not
rely on java.util.function, java.util.streams, or java.time. If that were
the
I think we can require Java7 or 8 to build GWT applications, but we need to
make sure that GWT applications can be deployed to servers running Java6
for a while. This would mean not using any Java7 or 8 language features in
gwt-servlet and RequestFactory.
For many companies it is a problem to upgra
>
> I think we can require Java7 or 8 to build GWT applications, but we need
> to make sure that GWT applications can be deployed to servers running Java6
> for a while. This would mean not using any Java7 or 8 language features in
> gwt-servlet and RequestFactory.
> For many companies it is a
On Tuesday, October 8, 2013 12:35:36 PM UTC+2, Jens wrote:
>
> I think we can require Java7 or 8 to build GWT applications, but we need
>> to make sure that GWT applications can be deployed to servers running Java6
>> for a while. This would mean not using any Java7 or 8 language features in
>
> Re. Java, we should align with Oracle's lifecycles. Yes OpenJDK 6 is still
> maintained, but I can't see any reason not to mandate Java 7 (for the
> developer). For deployment, maybe we could say "the two latest major Java
> versions", which means 6 and 7 for GWT 2.6, and 7 and 8 for GWT 3.0
This discussion has covered what the general rules for dropping support for
browsers, APIs and JVMs should be. That's a good thing, but what I would really
like is for GWT to specify the actual dates when it is expected that GWT will
no longer support particular runtime server JVM versions and t
On Tuesday, October 8, 2013 3:31:09 PM UTC+2, Paul Robinson wrote:
>
> This discussion has covered what the general rules for dropping support
> for browsers, APIs and JVMs should be. That's a good thing, but what I
> would really like is for GWT to specify the actual dates when it is
> expect
I don't think we should be publishing general rules to the GWT website,
since in practice we won't consider ourselves bound to them. At this point
I think we're in general agreement that IE6/7 will be dropped after GWT 2.6
and the rest is still being discussed.
Dropping Java 6 support doesn't seem
>
> [...] since in practice we won't consider ourselves bound to them.
>
Why not?
-- J.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe from this group a
Le 8 oct. 2013 20:27, "Brian Slesinsky" a écrit :
>
> I don't think we should be publishing general rules to the GWT website,
since in practice we won't consider ourselves bound to them. At this point
I think we're in general agreement that IE6/7 will be dropped after GWT 2.6
and the rest is still
On Tue, Oct 8, 2013 at 12:15 PM, Jens wrote:
> [...] since in practice we won't consider ourselves bound to them.
>>
>
> Why not?
>
Because we'll either we'll forget about that page due to turnover or
something new will happen and priorities will change. Put it this way: how
much do you feel bou
But we now have a steering committee, and decisions are made in public so
anyone can bug you when you forget. That's a different situation than
before.
Le 8 oct. 2013 22:43, "Brian Slesinsky" a écrit :
>
> On Tue, Oct 8, 2013 at 12:15 PM, Jens wrote:
>
>> [...] since in practice we won't conside
In practice on open source projects, things happen because some person or
company volunteers to implement them and sees the project through to the
end. So I don't really see steering committee schedule-making as a process
that's going to work. The Google GWT team is going to set its own quarterly
g
I don't think we should make hard guarantees, but we should have roadmaps
and milestones. If you look at how Firefox and Chromium work, they put all
kinds of new HTML5 features on the wishlist, prototype implementations are
done behind experimental flags, but most don't make the cut. Finally, they
Sounds to me that you suddenly start talking about feature guarantees for
features that do not yet exist, e.g. supporting a new browser or a new HTML
5 API. That wasn't really my intention and maybe you misunderstood it.
What I was talking about are guarantees about how long *existing* "features
16 matches
Mail list logo