Re: [jakarta.ee-spec.committee] Incremental vs Big Bang thought experime

[Scott Stark <sstark@xxxxxxxxxx>]

The nature of the impact shifts from the spec project to the binary compatibility project it would seem. The easiest thing for the spec project to do is simply update the namespace in all associated apis, but then the binary compatibility burden exists outside of the spec project. 

What if each spec project had to provide a compilation compatibility library that ensured a Jakarta EE 8 user of that spec continued to at least compile. This would ensure there is a feature mapping from Jakarta EE 8 to the latest rev of Jakarta. I’m feeling that the separation between specification and the need to support Jakarta EE 8 is a false one in that any work avoided at the spec level will have to be made up in a binary compatibility project and/or implementation level.

On May 29, 2019, at 12:02 PM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:

Scott,
My immediate response would be all of the API changes.  But, ...  I think you bring up a valid derivative for incremental.  As part of your exercise, could you go both ways to see what impact is?


---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:        Scott Stark <sstark@xxxxxxxxxx>
To:        Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:        05/29/2019 01:50 PM
Subject:        [EXTERNAL] [jakarta.ee-spec.committee] Incremental vs Big Bang thought        experiment
Sent by:        jakarta.ee-spec.committee-bounces@xxxxxxxxxxx

---

I’m going through a little exercise to help clarify where an incremental vs Big Bang approach might differ in terms of compatibility requirements as well as general effort. The context of the experiment is to update the enterprise security api to factor out the servlet specific and jsr-196 apis into a new package so that the HttpAuthenticationMechanism
Interface  or a variation of it could be used without those dependencies.

First question that comes to mind, under the incremental approach, would a change to the spec that only affects a subset of the javax.security.enterprise.* packages leave some packages under javax.security.enterprise.* and the changed classes under jakarta.security.enterprise.*, or when a spec is updated would all associated package be moved over to jakarta.*?
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee



_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee