Re: [incquery-dev] [viatra-dev] IncQuery API break (PSystem?) vsIncQuery

[Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>]

Hi,

answers inline

> On 2015. ápr. 21., at 11:09, Bergmann Gábor <bergmann@xxxxxxxxxx> wrote:
> 
> Hi,
> 
>> replacing the TypeUnary/TypeBinary classes with the TypeConstraint class breaks _every_ generated pattern matcher code available
> 
> True. Is it not OK to require the users to clean & build their projects after an upgrade to 1.0?
I am not _completely_ against it, if it is unreasonably expensive to provide a better way. However, I feel we have more and more users, and we can alienate them with incompatible updates, so we should aim to minimize the costs if possible.

> 
> If we think this is a problem, we can of course create completely fake TypeUnary etc. classes at the original package location that just instantiate TypeConstraint in their constructors; we can also add an Object field CONTEXT back to the superclass of generated query specifications; all that to trick the old generated code into compiling and working correctly even before it is first regenerated. Should I do this?
How much work is this? If one hour or two, I guess, it is worth it. If much more, then we should discuss it this afternoon.


> BTW, interesting observation: the ecore tests do pass on Jenkins, but not on Hudson. However, the school tests work fine on Hudson. So I am assuming Hudson uses pregenerated code for the ecore tests, while code is generated on the fly in all other cases? Weird.
> 
Sorry, but I don’t understand this. Are the school tests executing on Hudson?

Cheers,
Zoli
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics