[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [mdt-ocl.dev] Making useful progress
|
Title: Message
Kenn
- I would recommend always having another committer review changes; the
EMF and UML2 teams both work this way. Rather than trying to manage several
CVS branches, why not attach patches to the Bugzilla record (the way EMF and
UML2 do)?
Good point, 3
gears
- trivial
straight in
-
one-shot complete chnage via Bugzilla
- substantial
ongoing change via a CVS branch
- The time for collecting potential features for next year's Helios
release is now. Folks tend to work on what benefits their organization the
most (and they should have that right) but ultimately what's in the best
interest of the component's three communities (vendor/consumer, developer,
user) should be your guide.
- Technically, breaking API changes should be avoided, unless there is a
compelling reason to do so. Additive changes can be made as long as there is a
deprecation/migration plan. Perhaps you could start a wiki page to start
gathering input on features and poential API changes for next year...
There are a fair
number of pedantic API compatibilities that have been kept; for instance
the
CST maintains a
reverse order linked list of (oops! non-containment) constraints because that
was the way the LL original
parser worked.
1.3 added a sensible forward ordered containment array of constraints. Pruning
stupid CST structure
seems like a
no-brainer for 2.0. Tidying up the evolution of Environment and friends is
important but much more controversial.
We need to use
this list and the newsgroup to find out how much people care about some
clean-ups.
Ed
