[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cdt-dev] The Great Managed Build API Tooling Fiasco of 2009
- From: James Blackburn <jamesblackburn@xxxxxxxxx>
- Date: Wed, 22 Apr 2009 15:54:25 +0100
- Delivered-to: email@example.com
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=R2hKtgMnRBLhuke4PmABrZ5kYP2MhGlr6VY4FZwBaSk=; b=olpMeiS46hWkeTjF1c2ELAHqpxgqXu+KeFli2IAvzJ8Xk6GfgG2Zs7YYWeXuLeZpHH w88HEn7M4zF9JJwdEmE/81WAEUpD0yS+j2uHIZAcGBsUmvy2WGe99lQhVlu6YLwVfUZA D4AQBwj/gfo1nGSeoMLlRf2czFyNCrqoedH1g=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ATSZ1gTWlyaecS0u39RF7/v8IqpGOX+h46KoopaSiAULC/yYtZb6u0bfXlAbLLQBm8 atPyMJHXarCOmzFErXbNgRX/UOILN4IF8kZvoDfquiZst9Sye7zPk3uyQIv0wYvqq3wT zWZQUDXICJEYSQgG4U3l++S7KiqN8J5YDuGEc=
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.