[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
HA: [mdt-ocl.dev] Backwards compatibility for MDT OCL
|
Ed,
My idea to change to 3.0.0 in August is because I want to start activities for making 3.0.0 and 1.4.0 co-exist together, update releng, start publishing builds, etc. Moreover, I think it would be hard to keep everything in the form of bugzilla patches - and then apply a batch of patches in M3. I also don't think we should start yet another development branch for that and merge it with HEAD in M3. Let's ask Kenn whether it is ok to recommend the downstream projects to switch to 3.0.0 from 1.4.0 after M3.
Cheers,
Alex.
________________________________________
От: mdt-ocl.dev-bounces@xxxxxxxxxxx [mdt-ocl.dev-bounces@xxxxxxxxxxx] от имени Ed Willink [ed@xxxxxxxxxxxxx]
Отправлено: 27 июля 2009 г. 0:48
Кому: MDT OCL mailing list
Тема: Re: [mdt-ocl.dev] Backwards compatibility for MDT OCL
Hi Alex
I thought that all train projects were supposed to track the train, so that for instance QVTo should use M1 then M2 then M3 etc.
Milestones are there for early feedback. This was clearly necessary for p2 in Galileo that was very troublesome in M1 and M2
and only just made it for the RCs.
I was envisaging largely upward compatible enhancements only in M1 and M2; e.g addition of 'static' parsing. No change from 1.3.0/2.0.0.
Almost all the breaking API changes in M3 (possibly M4). Change to 3.0.0.
Bug fixes and further largely upward compatible enhancements in M4, M5, M6. Still 3.0.0.
I don't think that we're making such rapid progress that holding API changes back to M3 will be a problem. It's just bringing all
other changes forward to M3, at least in stub form, that may be hard.
Regards
Ed
Alexander Igdalov wrote:
Hi Ed,
I think we can use the style that would be most convenient for us. We are incrementing the major segment of the version number - since then clients should be aware of possible API changes and keep abreast of the latest sources.
But taking your considerations into account, I think a good idea would be to recommend the clients to start switching to 3.0.0 after say M3. Before that they can use 1.4.0. What do you think?
Cheers,
Alex.
-----Original Message-----
From: mdt-ocl.dev-bounces@xxxxxxxxxxx<mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx> [mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Willink
Sent: Sunday, July 26, 2009 9:33 PM
To: MDT OCL mailing list
Subject: Re: [mdt-ocl.dev] Backwards compatibility for MDT OCL
Hi Alex
When do we plan to make the name 3.0.0?
Every project that uses MDT-OCL will need to update its versioning. I was surprised how painful this was when playing with test plug-ins.
If we change for M1 with no API change having actually occurred, and change APIs bit by bit in M2, M3, M4. M5, we risk confusion and obscure mismatches of builds for users who allow CVS checkouts to persist across milestones.
I think it would be a good idea to prepare and discuss all our API changes, but hold back making any actual change till perhaps M3 when we do as much of the API change as possible in one go.
Regards
Ed
Alexander Igdalov wrote:
Team,
I have created a branch named OCL_2_0_support for backwards compatibility with MDT OCL 1.3.0 in Helios+ releases. Starting from now we can commit changes to HEAD - these modifications will affect MDT OCL 3.0.0 only.
Since Monday I am on holiday. I will get back to work on 13 August.
After that I will update the releng and refactor the code so that both
implementations do not interfere with each other. Volunteers to
perform this task earlier are welcome;-)
Cheers,
- Alex._______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx<mailto:mdt-ocl.dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx<mailto:mdt-ocl.dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx<mailto:mdt-ocl.dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
