|[wtp-dev] Please review our planned "Compatibility with previous releases"|
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.
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.
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.
= = = = = = =