Philipp, Ed,
Apologies for the confussion my email has provoked. Of course, I
didn't want to say that the current code is deprecated (the
components have not been marked as such, there has not been any
announce in the cross-project list, etc). IMHO, it's a matter of
time, tough. The main reason: the only active committer (to be more
specific, developer) is working on a new implementation which
is/will be compliant with future OMG specifications.
> How can we propose something mature as deprecated if
> - many other projects relay on it
Deprecation precisely makes clients know that the current
implementation won't be continued and there is a new implementation
to which they must migrate. Although such a migration should be done
as soon as possible (to benefit from the new implementation and
enhancements) the clients have, If my memory doesn't fail me, around
3 releases (3 years time) before the components are removed in a new
release.
> - the replacement is neither completely finished, nor its
completion if fully funded?
I hope that having a fully OMG compliant implementation is funded
enough. Of course, I'm not going to be the guy who will announce
such a deprecation, since I'm not working in the new implementation.
Again, apologies for the confussion.
Cheers,
Adolfo.
El 04/02/2012 13:00, Philipp W. Kutter | Montages AG escribió:
Hi,
Ed.
Thanks for your message, this is very useful information.
There a massive difference between
'mature' and 'deprecated'. I'm afraid that you are reading much
too much into a planning document which is looking at the
position we are trying to get to, not where we are today.
I did not bring the work 'deprecated' into the messages. As well,
I do not want to blame anyone else for using it.
I just asked for clarification from your side, which you did. I am
fully happy with what you write.
Regards, Philipp
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
|