[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ejb-dev] [cu-dev] Jakarta EE 10 and breaking changes
|
Steve,
Now we're getting into a much bigger discussion about whether to allow
incompatible API changes or to forever live by the Java EE backwards
compatibility model... Personally, I don't see how we survive long term
if we can never introduce incompatible API changes. We still need to be
cautious with any proposed incompatible API changes. But, to say that we
always have to have backwards compatibility is not sustainable (imho).
---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
From: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: jms developer discussions <jms-dev@xxxxxxxxxxx>, Kevin Sutter
<sutter@xxxxxxxxxx>, ejb developer discussions <ejb-dev@xxxxxxxxxxx>
Date: 05/05/2021 12:21
Subject: [EXTERNAL] Re: [cu-dev] [ejb-dev] Jakarta EE 10 and
breaking changes
Hi Kevin I think I was not clear either. I was saying one of the primary
goals of Jakarta EE is backwards compatibility which means breaking
changes are minimised. This means if we strictly follow semver then
Jakarta EE spec versions will appear ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hi Kevin
I think I was not clear either. I was saying one of the primary goals of
Jakarta EE is backwards compatibility which means breaking changes are
minimised. This means if we strictly follow semver then Jakarta EE spec
versions will appear to do very few major releases, in extreme cases only
1.x series. Under strict semver only when we remove some long deprecated
functionality would we have an actual breaking change and a major version
number. My point is, is this good marketing?
Steve
Get Outlook for Android
From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Kevin Sutter
<kwsutter@xxxxxxxxx>
Sent: Wednesday, May 5, 2021 6:01:04 PM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: jms developer discussions <jms-dev@xxxxxxxxxxx>; Kevin Sutter
<sutter@xxxxxxxxxx>; ejb developer discussions <ejb-dev@xxxxxxxxxxx>
Subject: Re: [cu-dev] [ejb-dev] Jakarta EE 10 and breaking changes
Sorry, Steve, I wasn't clear... I was not trying to say that we should
not ever introduce incompatible changes. What I was trying to say is that
we should use incompatible changes to indicate a major version update. If
the next version of Concurrency API is not introducing incompatible API
changes, then stay with the major version of 2.x. But, if the Concurrency
API is introducing incompatible changes, then the move to 3.0 is
warranted. I'm fine and happy with Concurrency (or any other Spec)
introducing incompatible changes, but let's use semantic versioning to
indicate that type of update.
-- Kevin
On Wed, May 5, 2021 at 11:55 AM Steve Millidge (Payara)
<steve.millidge@xxxxxxxxxxx> wrote:
I understand semver but if the goal in JakartaEE is not to make breaking
changes then we won't get many major versions of specifications? Is that
good?
Get Outlook for Android
From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Kevin Sutter <
kwsutter@xxxxxxxxx>
Sent: Wednesday, May 5, 2021 5:50:59 PM
To: ejb developer discussions <ejb-dev@xxxxxxxxxxx>
Cc: jms developer discussions <jms-dev@xxxxxxxxxxx>; cu developer
discussions <cu-dev@xxxxxxxxxxx>; Kevin Sutter <sutter@xxxxxxxxxx>
Subject: Re: [cu-dev] [ejb-dev] Jakarta EE 10 and breaking changes
Hi,
Getting back to the original question of whether Concurrency should update
their major version or not... You should be considering semantic
versioning (https://semver.org/) when making this decision. If you are
not making any incompatible API changes, then you should not increase your
major version -- even if you are introducing "lots of new functions". You
should be making this decision based on the technical aspects of your
Specification and how you want your users to easily consume your APIs.
Users need the ability to know whether a move to the new version of
Concurrency will break their applications or not without having to dig
through documentation. The use of semantic versioning allows for this. If
Concurrency moves to version 2.x, then users will know that their
applications will continue to work when they move up. But, if Concurrency
moves to version 3.0, then users have to make a conscious decision whether
it's worth the effort to move up. And, as implied by the previous
replies, if Concurrency 3.0 actually doesn't introduce any incompatible
changes, then you have tainted the versioning strategy and your users
won't know whether to trust the numbering scheme going forward.
The use of semantic versioning by the independent Specification Projects
is strongly encouraged, but it's currently not enforced.
Thanks,
Kevin
On Wed, May 5, 2021 at 11:23 AM Ivar Grimstad <
ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi Gurkan,
Thanks for your interest!
By contributing to the projects via mailing lists, issue trackers, pull
requests, you can ultimately be nominated and elected on board as a
committer. The normal open source rules of engagement apply to both
specification- and implementation projects.
https://www.eclipse.org/projects/dev_process/#2_1_Open_Source_Rules_of_Engagement
Ivar
On Wed, May 5, 2021 at 6:13 PM Gurkan Erdogdu <gerdogdu@xxxxxxxxxxxxx>
wrote:
Hi
I am happy to work on both EJB and JMS side. Who is responsible for adding
me to EJB/JMS spec and EJB/JMS implementation?
Gurkan
On 5 May 2021, at 14:34, Steve Millidge (Payara) <
steve.millidge@xxxxxxxxxxx> wrote:
I think both EJB and JMS are missing release plans. I hope they will both
start some time in the next few months.
Steve
From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> On Behalf Of arjan tijms
Sent: 05 May 2021 12:27
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: Re: [cu-dev] Jakarta EE 10 and breaking changes
Hi,
I wonder, is there actually any EJB activity to speak of recently? There
doesn’t seem to be much of anything planned for EE 10 there.
Kind regards,
Arjan
On Wednesday, May 5, 2021, Steve Millidge (Payara) <
steve.millidge@xxxxxxxxxxx> wrote:
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
From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> On Behalf Of Nathan Rauh
Sent: 04 May 2021 22:56
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: Re: [cu-dev] Jakarta EE 10 and breaking changes
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
_______________________________________________
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
--
Ivar Grimstad
Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation -
Community. Code. Collaboration.
_______________________________________________
ejb-dev mailing list
ejb-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ejb-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cu-dev
