Regarding your comment "I won't be surprised if the community decides not to specify
backward compatibility."
For me make sense, and just support backward compatibility only from Jakarta EE 9 and beyond, due Jakarta EE 8 still been oracle brand and can be tricky from the legal side handle the support.
The key change for Jakarta EE 9 is the namespace change.
Pruning reduces the amount of work to be done there.
I don't expect to add any completely new specifications, but if it
can be done with minimal impact on the other work it's worth
considering.
Jakarta EE 9 may not be the right time to add new profiles, mostly
because of the TCK work required to support new profiles.
I would hope that API enhancements would be modest.
I won't be surprised if the community decides not to specify
backwards compatibility.
Whether you name the releases 9, 10, 11, 12 or 8.1, 8.2, 8.3, 8.4
doesn't really matter. The issue is how you decide the content of
the releases. Are the releases date driven or content driven, or
some combination? We haven't really decided a general approach, and
it might be different for each release. It's quite clear that the
community prefers releases more frequently than what was done for
Java EE, so I'm assuming a 6 - 12 month time frame, which likely
constrains the amount of content that can be included.
It took a lot of effort to get out a release that had no API changes
at all, so I don't think we yet know enough to predict how long it
will take to produce a Jakarta EE 9 release even with just some
minimal set of changes.
I guess we need more community input on the date vs. content
tradeoffs. Do we decide what we want and then it takes as long as
it takes? Or do we drive to a particular date and scale the content
accordingly?
Edwin Derks wrote on 10/1/19 1:58 PM:
Thanks Bill, it's a pleasure to see a detailed
document containing Oracle's position on Jakarta EE 9.
What I feel though, and I would certainly like to hear your
opinions on this, is that we are gearing up a lot of desired
changes to the platform for release 9:
- possible big bang namechange of javax
- possible
pruning of specifications
- possible
new specifications
- possible new profiles
- possible API enhancements
- possible backwards compatibility features
This is awesome of course, but do we really want to put all
of these topics (to some extend) in one "big bang" release
that will result in Jakarta EE 9? Alternatively, can we spread
ithese out over smaller releases like Jakarta EE 8.1, 8.2, 8.3
or Jakarta EE 9, 10, 11, 12 in order to shorten the time of
delivering any platform updates? Since we are now starting to
plan these changes, can we in any way start to define a (high
level) roadmap on these? To my current knowledge, a release
cycle for Jakarta EE
hasn't been determined yet, but maybe this will shape itself
when we start planning/estimating/roadmapping? I'm not only
curious about this myself, but the desire for some kind of
roadmap was also mentioned in feedback that I got from a few
community members I spoke to at Oracle CodeOne.
Hope this helps.
Kind regards,
Edwin
On Tue, 1 Oct 2019 at 22:15,
Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Excellent
strawman,
Bill. Thanks!
What about
Entity
Beans? You mention "client view", but did you also mean
to include Entity BMP and CMP Beans? I'd vote +1 for that
pruning
as well.
I noticed
that
you didn't include Jakarta Management in the Pruning list.
The other
Stable APIs were included to be pruned (Registries, RPC, and
Deployment).
Did you just just forget Management, or is there a reason
why you
wouldn't include that in your list to be pruned?
Any
justification
on which Java SE 8 APIs should be moved to Jakarta EE 9 and
which ones
shouldn't? Or, was it just gut reaction to usage scenarios?
Agree with
postponing
the MicroProfile decision until after Jakarta EE 9.
The TCK
work could
be initiated and completed at any time, right? Does it have
to line
up with Jakarta EE releases?
Other than
that,
I think this is a great start!
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx Twitter:
@kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
See attached for Oracle's
proposal
for Jakarta EE 9. We look forward to
continuing this discussion.
[attachment "jakartaee9.md" deleted by Kevin
Sutter/Rochester/IBM]
_______________________________________________
jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe
from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev