Dmitry, I don't think
this is a question for the Specs to determine whether to drop support or
not. This is a question of whether application servers (products)
should continue to support these older schemas.
As a point of
reference, Jakarta EE 8 supported everything that Java EE 8 supported.
So, all of the previous versions of the schemas were supported. That
was just part of the game plan for Java EE -- always backward compatible.
But, now as we
go forward with Jakarta EE 9, should we continue to require this support
of past schemas? As Bill points out, once Jakarta EE 10 comes out,
the ability to handle older schemas will be a requirement anyway. So,
lowering the bar by stopping this support of older schemas for Jakarta
EE 9 implementations only lasts so long from a work effort perspective.
Given all of this,
I still like the idea of making the support Optional. Existing Java
EE/Jakarta EE products will probably continue to support the older schemas.
But, it does allow for new implementations to start fresh with Jakarta
EE 9 schemas. The required processing for comparing older schemas
can be put off for one release. --------------------------------------------------- Kevin Sutter STSM, MicroProfile and Jakarta EE architect @ IBM e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter phone: tl-553-3620 (office), 507-253-3620 (office) LinkedIn: https://www.linkedin.com/in/kevinwsutter
Kornilov <dmitry.kornilov@xxxxxxxxxx> To:
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx> Date:
Re: [jakartaee-platform-dev] backward compatibility for descriptor schemas Sent
Does it make sense supporting older
schemas if we are breaking compatibility anyway? I would say that it’s
optional. I guess many specs would want to drop older schemas support and
it’s right time to do it now.
> On 20 Jan 2020, at 21:38, Bill Shannon <bill.shannon@xxxxxxxxxx>
wrote: > > 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