Re: [jakartaee-platform-dev] VOTE: backward compatibility for descriptor

[Mark Struberg <struberg@xxxxxxxxxx>]

+1 for option #3 as well.
Having the backward compatibility optional is a good compromise.

txs and LieGrue,
strub


> Am 27.01.2020 um 00:00 schrieb kzr@xxxxxxxxxxx:
> 
> #3 is my vote.
> 
> -Kenji Kazumura
> 
>> -----Original Message-----
>> From: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of
>> Bill Shannon
>> Sent: Wednesday, January 22, 2020 4:54 AM
>> To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
>> Subject: [jakartaee-platform-dev] VOTE: backward compatibility for descriptor schemas
>> 
>> After the discussion in today's meeting, I agreed to send out a list
>> of alternatives and ask for votes.  We'll tally the votes and make a
>> decision in next week's meeting.
>> 
>> Here's the alternatives we're considering:
>> 
>> 1. Support for Jakarta EE 8 and earlier schemas is *optional* in
>> Jakarta EE 9 products.
>> 
>> 2. Support for Jakarta EE 8 and earlier schemas is *required* in
>> Jakarta EE 9 products.
>> 
>> 3. Support for Jakarta EE 8 *but not* earlier schemas is *required* in
>> Jakarta EE 9 products; support for schemas earlier than Jakarta EE 8
>> is *optional* in Jakarta EE 9 products.
>> 
>> I'm not going to reiterate the pros and cons, but if you have any questions
>> about why or why not to support one of these options, let me know.
>> 
>> Note that the "earlier" criteria can be somewhat confusing since not all
>> schemas were updated in Jakarta EE 8 (really Java EE 8) so some of the
>> "most current" schemas are from Java EE 7 or earlier.  In such cases these
>> would still be considered Jakarta EE 8 schemas.
>> 
>> I'm sure there are other alternatives that are possible, but I don't think
>> we need to make this more complex at this point.
>> 
>> Vote now!  We'll decide next week.
>> 
>> Thanks.
>> 
>> 
>> Bill Shannon wrote on 1/20/20 12:38 PM:
>>> We need to update all the descriptor schemas to switch to a new URL.
>>> What should we do about support for the old schemas?
>>> 
>>> Should we handle this just like support for the old package names and
>>> leave it to products to decide whether or not to support the old schemas?
>>> 
>>> Or should we continue to require that products support all the old schemas
>>> as well as the new version?
>>> 
>>> 
>>> At first it seemed simpler and cleaner if new products with no need for
>>> backward compatibility could just support the new schema.  But just like
>>> in the past, the schemas will continue to evolve as the specs evolve and
>>> products will need to be able to support multiple schemas.  So, in the
>>> long run, it's not clear this really saves a lot for new products.
>>> 
>>> I guess I'm inclined to say that products must support all defined versions
>>> of the schema and this is not a "backward compatibility" issue.
>>> 
>>> Comments?
>>> _______________________________________________
>>> 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
>>> 
>> _______________________________________________
>> 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
> _______________________________________________
> 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