Date
1 - 4 of 4
New features in EE9 for Servlet-API 5.0?
|
Hi, Yes, all or almost all projects will go for rename-only indeed. For Faces we had started too with new features, but will explicitly exclude those. Security and its foundational specs will do rename-only releases as well. Same for Expression Language, Messaging and Interceptors. Kind regards, Arjan Tijms On Mon, Jan 20, 2020 at 4:56 PM Greg Wilkins <gregw@...> wrote:
|
|
|
|
Greg Wilkins
If most other projects are making their EE9 release a rename only release, then I think that servlet-api should follow and not try to be special. However, it will be a hassle for vendors managing releases for 4.0, 5.0 and 5.1... but probably down among the noise against the whole hassle of the rename anyway :( cheers On Mon, 20 Jan 2020 at 08:16, Greg Wilkins <gregw@...> wrote:
--
|
|
|
|
Hi, My understanding is that if we absolutely want, we can. But then we do have to diverge from the EE 9 release plan and create our own plan (and engage in review for that etc). As we can followup with a 5.1 immediately after 5.0 (there's no time limit, could even be days), my preference would be for 5.0 to be a rename release only. Kind regards, Arjan On Mon, Jan 20, 2020 at 8:16 AM Greg Wilkins <gregw@...> wrote:
|
|
|
|
Greg Wilkins
Dear ee spec group. The servlet-api project is trying to come up with our project plan for our 5.0 and 5.1 releases. The 5.0 release will be our javax->jakarta rename release and the key question we have is can we also put some new features into that release? Or does it have to be exactly like 4.0, but with only the name changed? There are some minor features that we really need to add to stay relevant to current browser and specifications. A key example is sime-site cookie support as proposed in https://github.com/eclipse-ee4j/servlet-api/pull/271 and the matching schema change https://github.com/eclipse-ee4j/jakartaee-schemas/pull/1 If changes like these cannot be in a 5.0, then we will need a 5.1 as soon as possible after 5.0. I understand that have a pure renaming release would give some degrees of simplicity when porting, but I'm not sure that helps much if soon afterwards we have to deal with demand for 5.1 Thus our question is - can we make some minimal additions to the API in 5.0 on the basis that they will be reviewed against the criteria of not hindering any automated porting tools of 4.0 to 5.0? regards |
|
|