| Re: [jakartaee-platform-dev] Oracle's position on Jakarta EE 9 |
Hi! Is there any big downside of splitting big-bang renaming and pruning into separate steps? Doing renaming in Jakarta EE 9 and pruning in Jakarta EE 10 would have one big up-side: Jakarta EE 9 would be available for general availability to everyone sooner. As a project manager I then have the option to migrate to Jakarta EE 9 (or try it in a PoC) but I am not forced to do it right away. I might want to do a PoC with EE 9 and then leap frog to EE 10. Of course all the candidates for pruning can be marked as "deprecated" in EE 9 then. If a candidate is removed in EE 10 can then still can be decided on the feedback from projects still relying on these parts. I haven't read through all the discussions and documents that have been established up to now. If any of this above contradicts something that has already been decided I just didn't know :-) Best regards Tobias Am 03.10.19 um 10:53 schrieb Martijn Dashorst: > On Thu, Oct 3, 2019 at 10:20 AM Mark Thomas <markt@xxxxxxxxxx> wrote: >> Pruning - No view as it doesn't impact the specs Tomcat implements. >> API Compatibility - I'd like to see the API elements that have been >> deprecated for many years finally removed. I wonder if it is worth >> having a more defined process for removal such as "deprecated in n >> releases and removed in the n+1th release" > On both these I'd suggest doing that in the release *after* the package rename. > > As a consumer of the APIs in my multi-million lines of code projects I > don't want to conflate API changes due to the rename with API changes > because of grinding an axe. > > Removing old cruft, while it has it merits, means more discussions: > TCK's need to be altered beyond the package rename, interoperability > between specs need to be discussed. It opens up the process for much > more delay. > > I'd urge the Jakarta community to do focused releases: > - Java EE 8 -> Jakarta EE 8: transition 'as is' from Oracle to > Jakarta, including all the paperwork, documentation and TCKs. > - Jakarta EE 8 -> Jakarta EE 9: rename all the things: make the world > live in the jakarta package > - Jakarta EE 9.x/10.x -> evolve the specs to your liking > > I understand the allure of removing cruft from the APIs, but the thing > is that folks have workarounds in place that can/will fall over when > you remove the cruft. This will break if you conflate the package > rename with cleanup, and you won't know exactly if it is broken due to > the package rename or cleanup. > > Martijn Dashorst > _______________________________________________ > jakartaee-platform-dev mailing list > jakartaee-platform-dev@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev -- Frech IT GmbH / Am Brünnele 7 / 71642 Ludwigsburg phone : +49-(0)7141-9113037 / HR B 744851 / AG Stuttgart -------------------------------------------------------- Geschäftsführer: Tobias Frech mobile: +49-(0)172-7112352 / email: tobias@xxxxxxxxxx
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature