Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] The Great Managed Build API Tooling Fiasco of 2009

As as said I am fine with it if we can make an exception. And I am not planning it now, it is just usually what happens when we try to fix something
in managebuild in maintenance stream.

James Blackburn wrote:
2009/4/22 Elena Laskavaia <elaskavaia@xxxxxxx>:
I agree. But manage build is not ready for this. I would rather enable it in
7.0 and clean up API as much as we can so we don't

I guess I don't see the difference between deferring API tooling
enablement, compared with enabling API tooling now and changing the
plugin version to 6.0 or 7.0 when we do end up breaking API.  AFAICS
with the latter we get a prod from the API tooling when we break
something and the community-at-large is notified.

Is what you're saying that the API breakages planned  will not to
coincide with the CDT / eclipse train major releases? I would still
argue for using the tooling, as it helps us get version numbers right,
and helps API consumers.  Whether the plugin's version number matches
the CDT version number is less important (to me) as long as we're
honest in what we deliver.

have to extend it later for just bug fixes. Again we never "broke" API as
far as I know in 5.0.x and was really trying not to change it at all
even we did not have API tooling for that piece.

Well API was changed which caused people to claim stuff had broken
when 5.0.2 was released.  This is all too easy to do if we're not
constrained in some way to treat maintenance branches as maintenance.

Cheers,
James
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top