I
agree we need to approach the EJB spec team formally.
I’ve had some informal discussions with people on that
spec and they were supportive. However I imagine in
the first instance they may deprecate their
annotation. I will reach out to them once we get the
release review out of the way. My understanding if we
can’t get agreement across the various specs we can
drop these proposals. It will be interesting to see
how these sort of things are discussed and resolved.
I
am in agreement if a major is only allowed via
breaking changes then we don’t qualify but I also feel
this is a major release. I will put that forward as
our position on the release review.
Steve
This
brings up a good point regarding the proposals in
our release plan for moving annotations from other
specs to Concurrency. For example, the
@Asynchronous annotation under
https://github.com/eclipse-ee4j/concurrency-api/issues/43 If
this is moved from Jakarta Enterprise Beans to
Concurrency rather than duplicated (I'm not sure
which was the intent), then the Jakarta Enterprise
Beans spec would need a major release update per the
removal being a breaking change to their spec (as
well as an issue planned for Jakarta EE 10 which I
don't currently see listed on their https://github.com/eclipse-ee4j/ejb-api/milestone/2)
Does anyone know if anyone from Jakarta Enterprise
Beans has been contacted or involved in these
proposals? This would also apply for @Lock
https://github.com/eclipse-ee4j/concurrency-api/issues/135and to
some extent @Schedule https://github.com/eclipse-ee4j/concurrency-api/issues/98.
Getting
back to the Concurrency release, if the direction we
are being given is that breaking changes is the only
justification for increasing the major version, then
we don't meet it because we don't have a need to
make breaking changes. But my preference, if given
the choice, is that 3.0 would be a better indicator
to our users that there is a significant amount of
new function and API being added in this release.
From:
"Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To:
cu
developer discussions <cu-dev@xxxxxxxxxxx>
Date:
05/04/2021
11:11 AM
Subject:
[EXTERNAL]
Re: [cu-dev] Jakarta EE 10 and breaking changes
Sent
by: "cu-dev"
<cu-dev-bounces@xxxxxxxxxxx>
Just
for clarity. So we keep the major release even
though there may be no breaking changes?
Steve
From:cu-dev
<cu-dev-bounces@xxxxxxxxxxx>
On Behalf Of Nathan Rauh
Sent: 04 May 2021 14:13
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: Re: [cu-dev] Jakarta EE 10 and
breaking changes
+1 to
what Reza stated. Looking over the release plan, it
adds a significant amount of major new function,
none of which requires breaking changes.
From: Reza
Rahman <reza_rahman@xxxxxxxxx>
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Date: 05/03/2021 02:02 PM
Subject: [EXTERNAL] Re: [cu-dev]
Jakarta EE 10 and breaking changes
Sent by: "cu-dev" <cu-dev-bounces@xxxxxxxxxxx>
Based on the scope of work, I think this is a major
release, not a minor (point) release. I do not
foresee any need for breaking changes.
Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an
individual community member and do not reflect the
views of my employer.
On May 3, 2021, at 11:40 AM, Steve Millidge (Payara)
<steve.millidge@xxxxxxxxxxx>
wrote:
As
part of our release review.
See
Jakarta
Concurrency 3.0 Plan Review by smillidge · Pull
Request #368 · jakartaee/specifications
(github.com)
I
am being asked if this is truly a major version
release. i.e. Are we going to make breaking changes?
WDYT
is this a major version or minor version based on
semantic versioning. Alternatively do we want the
freedom to make breaking changes even if we haven’t
specifically identified any as yet?
Steve
Millidge
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev