On 07/04/2015 09:10 AM, Konstantin
Komissarchik wrote:
From the process side, the main thing you loose is ability
to control your releases. Only a project can release. If you a
part of WTP, you are tied to WTP release schedule, which may be
a problem for some adopters that are on a faster release cycle.
For instance, you would not be able to do the first release
until June of next year, unless you can convince WTP leadership
to allow this feature into a service release.
The effort we've made in making JSDT easy to build locally and by
providing an additional dedicated build and p2 repo for JSDT
snapshots goes in the direction of allowing it to deliver faster
than WTP, and if not releasing it, to allow users and integrators to
get access to more recent builds more easily.
In that context, I believe it would be totally do-able to make a
JSDT release for SR1 or SR2 if we want to (and it seems more and
more likely). As long as JSDT relies on stable APIs of WTP, it
shouldn't cause any issue. Such a release could include a JSON
editor.
In the end, I (and some others) don't believe in the concept of a
simultaneous build/release for WTP. There are too many things in it
that don't evolve at the same time at all, and the benefit of a
simultaneous build/release is quite questionable since the Eclipse
release train already takes care of that.
The next step for WTP seems to turn into a container project, just
like Tools or Technology, and to let individual projects live their
own lifecycle (but still discuss together via mailing-list) rather
than adding constraints that are clearly not in sync with nowadays
needs in adoption of technologies.
|