> without it the dependencies/target platforms are not resolved
> deterministically.
>
> And just to be clear what I mean with deterministic is that if our TP
> says org.x.z.y-1.2.3
> and the update site only have org.x.z.y-1.2.4 the build *must* fail.
>
> It doesn't if the other p2 metadata features/plugin's allows 1.2.4 in
> its set.
Let's keep in mind that the plugin/feature being built determines the versions of its
dependencies (not sure how fuzzy this gets when specifying package dependencies), so it
shouldn't matter what the TP says as it is _not_ the definitive source. The build
should fail if the plugin requires v1.2.3 and only 1.2.4 is available.
Yes of course, but plugins doesn't require v1.2.3 it has a range.
We use the .target file to ensure that range is deterministic between builds.
I'd also question why ..x release would break a build. The minor
version should be updated if the API changes. Of course, we sometimes use non-public API
or unreleased API, so these things can happen. When they do, the plugin with the
dependency needs to be updated to require 1.2.3 as the maximum supported version.
Yes - which is where multiple .target files becomes relevant to test such cases.
Remember, the user can be installing these into any platform that
supports the requirements of the plugins/features being installed.
Yes - but thats a separate case.
Target platform is a guideline, not a rule (with the exception for
package dependencies above, but, if the plugin is version dependent, it should be
specifying a version dependency somewhere).
Target platform is the way to specify what build and test against.
Thus it is the deciding factor when building and ensuring consistency an we know what we
build against.
Testing should then be run against updatesites that has minimum and maximum versions and
here using it against "real world" updatesites such as
eclipse.org etc.
/max