Similar to the "Target Environments", I am going to encourage all projects
to better specify their "Compatibility with previous releases".
I went and looked at our wtp-plan.xml file to see if we provided a good
example, and it appears we have left that section of our plan completely
blank for the past several releases! Maybe we felt we said enough
elsewhere?
At any rate, I have taken a stab at what I think our WTP general approach
is, and am hoping all committers (and PMC) can review to make sure it
matches your expectations.
http://www.eclipse.org/projects/project-plan.php?projectid=webtools#compatibility
Again, the goal is to document our plans about compatibility, if we would
accept bugs, etc ... I am not trying to push for any changes to what we are
already doing. I hope we are doing what I've documented :) but that's why
I'm sending this note. Let me know if I've lost track or misunderstood.
I hope there is time to discuss at Thursday's status meeting.
Thanks.
For your reviewing convenience, there is the current write-up.
= = = = = = =
Compatibility with Previous Releases
In general, we in WTP strive to provide the same type of compatibility as
the Eclipse Platform.
API compatibility. WTP 3.4 will be compatible with APIs declared in WTP 3.3
and WTP 3.2. See also WTP API Policy.
Workspace compatibility. A workspace being used with WTP 3.3 or 3.2 should
still open and work with WTP 3.4. In general, though, once a workspace is
opened with WTP 3.4, there is no guarantee it will continue to work with
older versions (that is, there may be some one-time migration of some
workspace meta data that prevents it being usable in older versions.
Project compatibility. A project being used with WTP 3.2 or 3.3 should
still be capable of being imported into and work with WTP 3.4. In general,
a project being used with WTP 3.N should be able to co-exist with using the
project with 3.N-2 ... as long as no new function from 3.N is used. This
use case is motivated by adopters supporting large development shops (say,
of 20 to 100 developers) who can not all necessarily "move up" to latest
version at the same time. They should all be able to normally share the
same project, via SCMs and similar, until they all are able to move to
common development version or until they use some new function in the
latest release (which, of course, would not be present in the previous
releases). Note, it is hard to completely guarantee this will always work
since there is no "common API" or spec that says how to guarantee it. While
we will make every effort to write good code that is "forward
friendly" (such as, code that knows to ignore preferences or metadata that
is not understood rather than blindly throwing an exception and failing or
writing thousands of error messages to the log, we depend heavily on
adopters reporting bugs they find in the many possible "co-existence
scenarios". We'll consider bugs on this topic as valid and prioritize them
along with other bugs. In cases where they can not be fixed, we will
explicitly call out "co-existence" exceptions in our release or migrations
documentation.
= = = = = = =
_______________________________________________
wtp-dev mailing list
wtp-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/wtp-dev
