Re: [wtp-pmc] suggested requirements wording change

[David M Williams <david_williams@xxxxxxxxxx>]

While I don't disagree with the
sentiment expressed, there are some parts I'm not sure should be part of
our requirements statement ... since either I can not imagine how they
could be made to work, or the standard is higher than other Eclipse projects,
or it interferes with correct componentization, or interferes with transparent
use by adopters. 

<quote>
Attempts to use (or convert to)
new 2.0 functionality that cannot be made backwards compatible with 1.5
must clearly identify to the user that 1.5 interoperability will be lost
as a result; this confirmation should only happen the first time such a
request occurs on a per project basis
</quote>

I do not know of other projects
that "give warning" to the end user (after all, its a team decision
:)  ... and for good reason. I think 1) its hard, 2) people who do
not have previous version do not care (and we do not know if they do or
do not), 3), it "surfaces" WTP in some funny ways that adopter
products may not like ... e.g. Company's ABC product LMN would "suddenly"
say "not compatible with WTP 1.5"? 
I *think* other Eclipse projects
have simply well documented the compatibility issues, and left it at that
(for example, using linked resources). 


<quote>
Manual conversion of a 1.5 project
to a 2.0-only status shall also be supported, and may enable performance
or functionality advantages versus the interoperable mode. A preference
shall exist that enables users to indicate that all new projects are created
as 2.0-only (non-interop); the setting of this preference in the 2.0 release
shall be “false”.
</quote>

This has similar "adopter
product" issues as above, but in addition, is little more than a "global
variable", which is bad bad bad for componetization ... such as, what
if it was something that effected only EJB's, but some "adopter products"
might not even use the EJB features ... in other words, adopters do not
have, and should not need to have, the concept of an "embedded WTP"
... it should basically be invisible. 

So .. I'd suggest the following
wording for our requirements statement, which I think covers the immediate
goal of getting components to review their fragility of surviving future
changes to config data, etc., 
but does not "lock us in"
to any particular solution. As always, we can reexamine any of this issues
as concrete cases present themselves. 

<proposedrequirement>
 By default, WTP 1.5 should
work on projects created by WTP 2.0 users and shared via a repository.
Artifacts created by WTP 2.0 that are consistent with 1.5 features should
not break WTP 1.5, and where possible WTP 1.5 should either ignore or tolerate
any new artifacts in WTP 2.0 and subsequent releases. Attempts to use (or
convert to) new 2.0 functionality that cannot be made backwards compatible
with 1.5 must be clearly identify in documentation to the user
that 1.5 interoperability will be lost as a result; this confirmation should
only happen the first time such a request occurs on a per project basis.
Manual conversion of a 1.5 project to a 2.0-only status shall also be supported,
and may enable performance or functionality advantages versus the interoperable
mode. A preference shall exist that enables users to indicate that all
new projects are created as 2.0-only (non-interop); the setting of this
preference in the 2.0 release shall be “false”.
</proposedrequirement>

"Tim Wagner" <twagner@xxxxxxx>
Sent by: wtp-pmc-bounces@xxxxxxxxxxx

05/11/2006 02:42 PM

Please respond to
"WTP PMC communications (including coordination, announcements,  and Group discussions)" <wtp-pmc@xxxxxxxxxxx>

To	"Arthur Ryman" <ryman@xxxxxxxxxx>
cc	"WTP PMC communications (including coordination, announcements, and Group discussions)" <wtp-pmc@xxxxxxxxxxx>
Subject	[wtp-pmc] suggested requirements wording change

Existing text:
 
·
 A WTP 1.5 should also be able to work on projects created by WTP
2.0 users and shared via a repository. Any new artifacts creates by WTP
2.0 should not break WTP 1.5. WTP 1.5 should either ignore or tolerate
any new artifacts created by WTP 2.0.
 
Suggested text:
 
·
 By default, WTP 1.5 should work on projects created by WTP 2.0 users
and shared via a repository. Artifacts created by WTP 2.0 that are consistent
with 1.5 features should not break WTP 1.5, and where possible WTP 1.5
should either ignore or tolerate any new artifacts in WTP 2.0 and subsequent
releases. Attempts to use (or convert to) new 2.0 functionality that cannot
be made backwards compatible with 1.5 must clearly identify to the user
that 1.5 interoperability will be lost as a result; this confirmation should
only happen the first time such a request occurs on a per project basis.
Manual conversion of a 1.5 project to a 2.0-only status shall also be supported,
and may enable performance or functionality advantages versus the interoperable
mode. A preference shall exist that enables users to indicate that all
new projects are created as 2.0-only (non-interop); the setting of this
preference in the 2.0 release shall be “false”.
 _______________________________________________
wtp-pmc mailing list
wtp-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-pmc