[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] Xtext clients on the train
|
Guys,
It's clear that no matter what, in the end, there are trade-offs to be
made. I strongly encouraged the Xtext team to make exactly the
trade-off they chose. I have a very strong aversion to trying to get
two coexisting versions of Xtext on the train. I also have a very
strong aversion to forking the code (package renaming) in an attempt to
make all the clients happy: it means the clients using the new fork has
lots of work to do to, and also result in two versions on the train. It
all sounds like bad news to me. Best case scenario is if all the
clients on the train move to the new version and only the new version is
on the train. More comments below.
Ed Willink wrote:
Hi
So, are you saying: if I have some Xtext 1.0 plug-ins and
I want to run them in an eclipse installation that has
Xtext 2.0 installed, it will not work?
Yes, exactly.
We discussed that at ESE, didn't we? ;-)
I think it's a bit nastier than that. You cannot even install a mix of
Xtext 1.0 and Xtext 2.0 plugins, so if some important provider insists
that their Xtext 1.0 tool is definitive, they block everyone else.
So we can't have that on the train. We must all move. It's generally
the case that plugins that provide or use extensions are singletons so
trying to make them coexist is a problem. It will generally be
impossible to have two major versions support all clients since by
definition, the reason for the major version increment is breaking APIs...
Migration shouldn't be too much work and we are actively helping
other open-source Xtext consumers to migrate.
I can confirm that the migration for developers is very tractable; but
that is no help for users.
The users will have to choose to use an older version or a newer one.
So they should be able to provide both an Xtext 1.x and an Xtext 2.0
version.
Not easily. It is very inconvenient having to provide two variants of
the path and spelling of INode throughout custom code.
No kidding. That's why I don't want to see the Xtext folks themselves
forking their code.
While I appreciate that with foresight the idea of a compatibility
layer may have seemed unreasonable. Now with hindsight I think it may
prove much easier. Certainly the code that I have needed to change
doesn't seem like it really changes significantly at all.
Exactly. I expected migration would be easy so with that insight in
mind, I suggest we make the problem even simpler by looking forward and
not backward. Everyone has way more than enough to do as it is.
Regards
Ed Willink
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
