| Re: [ejb-dev] [cu-dev] Jakarta EE 10 and breaking changes |
would recommend that the EJB specification not be updated. Developers that are
content with the current version of @Asynchronous, @Schedule, @Timeout, @Lock
can stick with the old EJB versions, but those looking for the newer, simpler, modern,
cloud friendly versions should move to use CDI and concurrency.
A little off subject, but since the EJB mailing list has been pulled in here, I will add that I am
supportive of some of the EJB capabilities being advanced in the concurrency spec,
but I don't think this should be pursued as a move, but rather a progression.
Approaching this as a move would likely result in Jakarta Concurrency supporting some
of the EJB specific uniqueness of the features, making it more complex than it needs to be.
For example, is there really a need for persistent timers? Instead, the concurrency
spec should learn from the EJB spec, but do it better; modernizing the features;
advancing them.
I would recommend that the EJB specification not be updated. Developers that are
content with the current version of @Asynchronous, @Schedule, @Timeout, @Lock
can stick with the old EJB versions, but those looking for the newer, simpler, modern,
cloud friendly versions should move to use CDI and concurrency.
The breaking change should be in the move from EJB to Concurrency; the EJB spec
itself should not introduce breaking changes for this.
-- Tracy Burroughs (tkb@xxxxxxxxxx)
"ejb-dev" <ejb-dev-bounces@xxxxxxxxxxx> wrote on 05/05/2021 04:59:42 PM:
> From: Emily Jiang via ejb-dev <ejb-dev@xxxxxxxxxxx>
> To: ejb developer discussions <ejb-dev@xxxxxxxxxxx>
> Cc: Emily Jiang <emijiang6@xxxxxxxxxxxxxx>
> Date: 05/05/2021 05:00 PM
> Subject: [EXTERNAL] Re: [ejb-dev] [cu-dev] Jakarta EE 10 and breaking changes
> Sent by: "ejb-dev" <ejb-dev-bounces@xxxxxxxxxxx>
>
> To manage the versioning scheme automatically, I strongly recommend
> to use the bnd baseline plugin as I mentioned in the other topic on
> semantic versioning.
>
> Thanks
> Emily
>
> On Wed, May 5, 2021 at 6:35 PM Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
> +1 Steve. I think there is a balancing act here between strict
> versioning rules and expressing to users the subjective scale/value
> of features in a release.
> 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 5, 2021, at 1:21 PM, Steve Millidge (Payara)
> <steve.millidge@xxxxxxxxxxx> wrote:
>
> 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 @Lockhttps://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
> _______________________________________________
> cu-dev mailing list
> cu-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/
> mailman/listinfo/cu-dev
> _______________________________________________
> ejb-dev mailing list
> ejb-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/
> mailman/listinfo/ejb-dev
>
>
> --
> Thanks
> Emily
> _______________________________________________
> ejb-dev mailing list
> ejb-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/
> mailman/listinfo/ejb-dev
_______________________________________________
ejb-dev mailing list
ejb-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ejb-dev