[cc: gwt-contrib, please follow-up there]
On Tue, Oct 8, 2013 at 10:06 AM, Artur Signell ar...@vaadin.com wrote:
On Oct 8, 2013, at 4:59 AM, Matthew Dempsky mdemp...@google.com wrote:
On Mon, Oct 7, 2013 at 1:17 AM, Joonas Lehtinen joo...@vaadin.com wrote:
Furthermore we should decide if
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
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
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
expected
[...] 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 and
Le 8 oct. 2013 20:27, Brian Slesinsky skybr...@google.com 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
On Tue, Oct 8, 2013 at 12:15 PM, Jens jens.nehlme...@gmail.com 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
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 skybr...@google.com a écrit :
On Tue, Oct 8, 2013 at 12:15 PM, Jens jens.nehlme...@gmail.com wrote:
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
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
15 matches
Mail list logo
