Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Xtext clients on the train


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:
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.


        Ed Willink

cross-project-issues-dev mailing list

Back to the top