| Re: [jakartaee-platform-dev] Jakarta 10.1? |
Hi,
here are my thoughts:
A Jakarta EE 10.1 release, following semver rules, could add support to
new features, but is not allowed to drop something, meaning doing a
breaking change.
So in a Jakarta 10.1 Release we could add Java SE 21 support, but not
allowed to drop Java SE 11. However, as Scott pointed out, if there is
direct use of the SecurityManager API in at least one Jakarta
specification API (or SPI) of an intended to be part of at least one
Jakarta EE 10.1 profile, it is impossible to achieve a minor release
without breaking at least one of the semver rules.
In a minor release we could address some minor changes like addressing
some of the dependency issues in the APIs, deviating uses of them in
the corresponding TCKs as far as they to not break anything beside bug
fixes. A subset of these examples could be addressed in a API
service/patch release too.
May be it would be a good idea sorting the change requests regarding
their semver impact, and if there enough changes and supporters for
spending resources on it, we can do a release.
An interesting alternative to a final minor/patch/service release could
be to do mandatory milestone releases on a major release to address
specific changes, i.e.:
* require Java SE 17 as a minimum (dropping Java SE11 support)
* support for Java SE 18+ temporarily (removing SecurityManager
dependencies)
* support for Java SE 21 (when available)
* may be, require Java SE 21 as a minimum (if agreed later)
* TCK split up towards component spec
* Breaking changes of a (sub-)set of component specs (to fulfil
alignment of depending higher level specs)
* etc.
These milestones could limit the risks for a major release and could
give transparency during the release.
There are many reasons for the delay of Jakarta EE 10, but one
significant is the complexity of the platform and some lack of
visibility during the release process, leading to us to address issues
in a more serial instead of a parallel way - and at the end accumulating
time on the critical path of the project.
Another idea is to move forward using 'Continuous Integration technics
that are best practices in application development for a long time.
I am dreaming from something as simple as
git clone <jakarta.project.url>
mvn clean verify
to get valid feedback for changes on the spec and the registered
Compatible Implementation(s) for the upcoming release.
Heading for that goal would increase quality (i.e. refactorings can be
done with limited risk) and release cadence (i.e. takes burden form the
release management to address issues manually and contributors do not
have to wait for somebody the run the test, that could be busy, on
vacation or simply sleeping because of a different time zone ;-) ).
@Steve: That last could be a point to the Jakarta EE 11 requested
release changes, but it would be independent of a specific release.
The jQA Jakarta EE dependency analysis is step in that direction,
splitting up the TCK would be another...
I agree, this is a very valuable conversation in deed.
Best,
Jan
Am 06.10.22 um 20:38 schrieb Scott Marlow:
>
>
> On 10/6/22 11:38 AM, arjan tijms wrote:
>> Hi,
>>
>> In a similar vein to how we did Jakarta 9.1, what about doing a
>> Jakarta 10.1 that only focuses on the security manager removal and
>> JDK 17?
>>
>> Jakarta 10.1 would then make sure that all TCKs are updated to not
>> use the security manager in any way, and subsequently only JDK 17 is
>> tested. Implementations certifying for Jakarta 10.1 are therefore
>> guaranteed to run without a security manager and are also guaranteed
>> to run at least on JDK 17.
>
> During the EE 9.1 development, David reminded me that TCK tests need
> to work on both eager/lazy class loading JVMs. In order to pass on
> eager class loading JVMs, classes that reference the Security Manager
> classes cannot be loaded or they will get a class not found exception
> (CNFE).
>
> I think we need to concentrate our effort on EE 11, otherwise we won't
> complete the release in a timely manner. Also due to the eager class
> loading JVMs which we would want to support I think, the security
> manager needs to to be removed from the SPEC APIs also (to avoid CNFE
> failures), which requires a major EE release I think.
>
>
>>
>> The work for Jakarta EE 11, which mainly takes place in the component
>> specification projects, can largely or even entirely continue in
>> parallel.
>
> My preference is to start on EE 11 now and not delay starting the work
> which includes a lot of TCK changes that need to happen before we
> start any SPEC Ballots (we might be able to do some parallel effort
> but once ballots start, TCKs that are used must be completed).
>
>
>> Thoughts?
>
> Thanks for starting this thread to discuss now! A lot of good feedback!
>
> Scott
>
>>
>> Kind regards,
>> Arjan Tijms
>>
>> _______________________________________________
>> jakartaee-platform-dev mailing list
>> jakartaee-platform-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visithttps://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