For the record:
It seems the whole decision about whether to use semantic versioning is NOT settled yet. The ticket for it is still open and unresolved to this very day:
I also found no VOTE about it on any list.
So to me it seems that the handling was not really kosher. Good at creating rules, even better at breaking them immediately... But then again, a more important question is: does it make sense for users/consumers of Jakarta EE? Is it worth for them, or does it only benefit one certain implementation (which is not even Jakarta EE but seems to be the origin of this change)?
Imo we should raise awareness that backward compatibility in the past used to be one of the key selling arguments pro JavaEE. Do we want to ditch this if there is no really good reason (as in this specific case, see my question list above)?
LieGrue, strub Am 28.01.2023 um 20:13 schrieb Reza Rahman <reza_rahman@xxxxxxxxx>:
Looping in the CDI mailing list so that the right folks can
provide additional context. My guess is that these decisions were not taken particularly
lightly. I think it is easy to see performance is a key value
proposition for CDI Lite/Jakarta EE Core runtimes. There is some
evidence to suggest that this line of thinking actually is making
Jakarta EE more relevant to newer audiences.
On 1/28/2023 1:28 PM, Mark Struberg
wrote:
Sorry, but the whole referenced
email threads does NOT cover pruning rules at all!
The whole question is about guaranteed stability over a
forseeable version range.
I have no problem with deprecating features.??
I also have no problem with pruning long time deprecated
code.
But I DO have a problem with intentionally (or planlessly)
breaking backward compatibility from one EE version to the
next *WITHOUT* any reason!
For swapping the default meaning of empty beans.xml files
please ask yourself:
* was there really no other way to solve the problem?
* was there a groundbreaking new feature which would not
have been possible without this change?
*
was this change thus really technically necessary?
* was it worth to break the world just because someone
thought it might be funny?
Please elaborate!
txs and LieGrue,
strub
PS: failures as such can happen, no problem. But then
let's solve/undo those failures and not codify them!
I created an issue to update the page:
I don't know that there was ever a
formal vote, but the context is found in this issue
and platform thread.
https://github.com/eclipse-ee4j/jakartaee-platform/issues/449
I would also like to see the discussion
or minutes from a meeting where this was
decided. I believe that this is a thing that
requires a ballot.
It??s true that we had to bend the rules
for Jakarta EE 9, but it's not a reason to
keep bending the rules for all the future
releases. It's also true that Jakarta EE 10
dropped some deprecated functionality, which
used to be allowed in Java EE but the rules
for Jakarta EE in https://eclipse-ee4j.github.io/jakartaee-platform/CompatibilityRequirements
don't cover this option. Even if those rules
are still valid, they aren't complete, and
even state this explicitly in one place:
XXX - This section needs to be
updated with new rules for the actual
removal of APIs and specifications from
the Jakarta EE platform as anticipated
in Jakarta EE 9, similar to what???s done
for the Java SE platform.
I suggest that we update the https://eclipse-ee4j.github.io/jakartaee-platform/CompatibilityRequirements
page to be up to date with the current
Backwards Compatibility Requirements
(Decided by whom? Jakarta EE Steering or
Specification Committee??? ). We can't accept
that we have an official document that we
don't follow, and, on the other hand, have
some unwritten non-transparent agreement
that some of us follow.
All the
best,
Ondro
Mihalyi
Director,
Jakarta EE expert
Omnifish O??, Narva mnt 5,
10117 Tallinn, Estonia | VAT:
EE102487932
Wow, really. I'm speechless.
Do the people who decide such
things IN THE DARK (aka undocumented
it seems) mean this serious?
I mean, really this got nowhere
made public, was it? Please point me
to the articles covering this!
That would imo TOTALLY ditch
the whole purpose of JavaEE /
JakartaEE in my eyes.
If a project wants to use
quickly evolving technologies,
then they do usually NOT choose
JavaEE.
JavaEE - in my experience - was
previously chosen by companies and
governmental organisations whose
primary goal is stability over a
very long period of time. We are
talking in 5 to 10 years of
stability. Now when you folks
ditch this, then I fear we will
loose banks, governments, etc.
Those 'slow moving dinosaurs' in
my experience used to be the main
users of JavaEE. They provide the
main money, they have the most
code running in JavaEE.
There is a good reason why
people used to say "JavaEE is
these days COBOL". That's because
COBOL apps are running till today.
Like many JavaEE apps I see at
customers. Many of them older than
10 years, but still perfectly
maintainable.
And for container vendors: why
should I pass a TCK if the rules
are totally turned around in 2
years anyway? I mean this is a
joke, really :(
LieGrue,
strub
PS: Scott, I understand you are
just the messenger, so no personal
offense meant.
We have
switched to a semantic
versioning approach, but
I don't see that this
was captured in that
page or elsewhere. That
notion of backwards
compatibility was
completely violated in
the EE 8 to EE 9 release
due to the package
rename, and in general,
maintaining such
stringent backwards
compatibility was seen
as counterproductive to
evolving the platform.
Hi!
I wanted to
ask whether
the following
document is
still valid
and applies to
Jakarta EE10?
Or is
there a newer
version and
where can I
find it?
txs and
LieGrue,
strub
_______________________________________________
jakartaee-platform-dev
mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this
list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
