[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cu-dev] [External] : Re: [ejb-dev] Jakarta EE 10 and breaking changes
|
- From: Ed Bratt <ed.bratt@xxxxxxxxxx>
- Date: Tue, 11 May 2021 09:44:10 -0700
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0EsTiJ5YfthjS1K9bb3DqJLfmgV08L/GFFaoUkfqSd8=; b=IcvWL/cw5pYJ6Udb/63GbpTBvZyzHz5zDZOm8bWSdq+Qq9fyCRryXwH1hhlDKlERuyZY6d2SioBd5YzGIGu48ViTuT2sV6djVMDof3zBHWICFDRNoNkQ2+O6d2r9AZq5U5yU/RUFHWMZNG9oWyH8KzQR06HOE23vdwR9UtbUpLb+U+aY7PitF+9nOCyznPNhU75qoPOPuRZ1GKKfDKfNZ43tQIS665hzEUp2QCTiddVWtrsKjGn/fKUvwnOigGeSS4psCHsTUVwRpyC/U1ifIbrXl28X9sJiBhG/i3AYuVhbkF+Z9bAsbfbQif+nlx1RimETxWniV2y4qavROOhNNA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=imlqsXSLdgWHxL6EPEaJ+8zJ5GoxC5bcARBQIM45QE5OccxW7KtvJhBEW25kAbp8IJi5Hr6IST3i/1/W3j/0SjaZh8CCpow61WESTZa5R/vbR5cf25fO3ghDmvyJovViBtUKD+Sry9Yz8/c1ZypNV5++HKtl5iwh17TPiIlVTskFNqmU6/pH+JN8MGBxayKtlTyyf70u0+w2hEnhQGvv665dOd4HX0HI7OXCaslA/b9sMNh98m0vOv8vzVAoe21QsbB3jRhgeaqYOQyzHC4ORPium+ZKttQTB24WOCd/Vc9ZVfuLH7zKk85OH9IRHkwvdW6zrViyShhgEt4RZtdY8g==
- Delivered-to: cu-dev@xxxxxxxxxxx
- List-archive: <https://www.eclipse.org/mailman/private/cu-dev/>
- List-help: <mailto:cu-dev-request@eclipse.org?subject=help>
- List-subscribe: <https://www.eclipse.org/mailman/listinfo/cu-dev>, <mailto:cu-dev-request@eclipse.org?subject=subscribe>
- List-unsubscribe: <https://www.eclipse.org/mailman/options/cu-dev>, <mailto:cu-dev-request@eclipse.org?subject=unsubscribe>
- User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
Hi,
I'd like to start the ballot -- two bits of data that might be
helpful:
First, while the committee thinks that Semantic Versioning should
be followed, it has not made that mandatory. So -- we may proceed
regardless. The committee would prefer starting this plan at a
minor release but if the group wants to specify major release, we
may proceed with that.
Second, the Platform team is considering establishing a
time-boxed approach and is likely to propose that Release Reviews
be planned by Oct 15, 2021. This is not confirmed, but based on
discussion from the most recent Platform Team meeting, earlier
today. If this date were factored into this Plan review, would
that change any of the proposed content?
Regardless, once you confirm that the plan proposal meets the
team's goals, let me know and I will initiate the ballot.
Thanks,
-- Ed
On 5/6/2021 3:31 AM, Steve Millidge
(Payara) wrote:
Can
we go forward with the release review and then choose later
in the release cycle the specific version number?
Maybe
we have to introduce a breaking change, maybe we don’t,
maybe we complete all the features, maybe we don’t. Problem
is at the moment until we develop the features we don’t
know. I thought the release record was just to provide rough
intentions rather than detailed design decision.
Steve
That's a
fair point, Reza. And, this is one of the reasons why we
are not enforcing semantic versioning. There may be cases
where a Specification decides that a major version update
is warranted due to the sheer number of new features going
in -- even if they keep the API compatible. But, I would
say this approach should be the exception and not the
rule.
+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.
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?
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.
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?
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.
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.
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?
I
think both EJB and JMS
are missing release
plans. I hope they
will both start some
time in the next few
months.
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.
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.
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
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/cu-dev__;!!GqivPVa7Brio!PrulGGnRWUOPUTVxkZVByy1qgBz8LdVq5fBhJJZ9ZO6cuEhwEPjNSL8U6aF8yqY$
