Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] VOTE: backward compatibility for descriptor schemas

#3, although I expect existing servers will keep support for older schemas.

El mié., 22 ene. 2020 6:38, Mike Love <mike.love@xxxxxxxxxxxxxxxx> escribió:
#3 +1

> On 21 Jan 2020, at 21:53, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
>
> 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


--

www.symbiotics.co.za <http://www.symbiotics.co.za>

********************************************************************************

This email and any accompanying attachments may contain confidential and
proprietary information. This information is private and protected by law
and, accordingly, if you are not the intended recipient, you are requested
to delete this entire communication immediately and are notified that any
disclosure, copying or distribution of or taking any action based on this
information is prohibited.

Emails cannot be guaranteed to be secure or
free of errors or viruses. The sender does not accept any liability or
responsibility for any interception, corruption, destruction, loss, late
arrival or incompleteness of or tampering or interference with any of the
information contained in this email or for its incorrect delivery or
non-delivery for whatsoever reason or for its effect on any electronic
device of the recipient.


********************************************************************************
_______________________________________________
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

Back to the top