I am not on the spec committee. I am just a guest. Even so, I agree that standalone specs should have more latitude to remove stuff. In the case of MVC, this is especially true.
If you were already using MVC as a standalone spec, you’re pretty cutting edge and you probably would be happy to be able to use MVC as part of the platform.
Ed
From:
jakarta.ee-spec.committee <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> on behalf of Scott Stark <sstark@xxxxxxxxxx>
Date: Wednesday, June 21, 2023 at 12:18
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakarta.ee-spec.committee] MVC Removal without Deprecation Exception
It should be part of the ongoing discussion, but my view as stated on the issue is that specs that are not part of a profile or platform should have more flexibility in what changes they make.
On Wed, Jun 21, 2023 at 9:15 AM Andrew Pielage <andrew.pielage@xxxxxxxxxxx> wrote:
It's been a bit of time since we did reviews and therefore the knowledge has all left my brain.
I was reviewing the plan for MVC and noticed that they're planning to remove something without deprecation.
Is there a process for allowing these exceptions? Should I add a small note to the usual ballot email drawing attention to it?
Or are we simply trusting ourselves to spot these cases before deciding to vote and we decide if we want to grant an exception in silos?
|
--
|
|
Andrew
Pielage
Senior Software Engineer
|
|
|
|
|
|
Payara Services Ltd., Registered office: Malvern Hills Science Park, Geraldine Road, Malvern, WR14 3SZ, United Kingdom
Registered in England and Wales: 09998946 | VAT: GB 193854467
|
|
Payara is a proud recipient of the prestigious Queen's Award for Enterprise:
International Trade 2021
|
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
