XWT had put their Neon releases bits into the repository several
months ago and then basically fell off the face of the Earth. In
this case, the problem was that XWT didn't follow the EDP until
the very last minute. While it's true that the consuming projects
could likely revert back to an earlier version, this would
actually be a significant and dangerous change this late in the
cycle.
On 13 Jun 2016, at 14:47, Eric Rizzo <eclipse-mail@xxxxxxxxxxxx>
wrote:
t's still not clear to me, however,
if other projects were explicitly dependent on the
non-release-ready version of XWT. In other words, the
question of whether a viable option was/is to include last
years's release train version in this years' train. I
realize in some cases that won't be viable (eg, a
downstream project is dependent on features or fixes not
in the previous release), but can it be kept as one option
when this situation arises?
This is actually a weird one.
XWT can be removed from the release train without
any harm. Any project participating in the release train can
bring in XWT as a dependency. In such a case, no additional
release train participation work has to be done by XWT. The only
requirement is that the bits in the release train repo are
*released* bits.
Now here is any interesting question ... out of the
thousand bundles in the release train repo, can anyone identify
non-released bits?
-Gunnar
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/technology-pmc
