[
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
|
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
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. I am fine with it if we can make an "exception" for API extensions (That have to be discussed in the mailing list
anyway if this happens after API freeze or in maintenance branch).
James Blackburn wrote:
2009/4/22 Elena Laskavaia <elaskavaia@xxxxxxx>:
I am not talking breakage I am talking about extension. When we going to
maintanance mode i.e. 6.0.1 it would real pain because some method in public
class declared private and not protected and so on. We hit a lot of with
5.0.2.
IMHO I don't believe we should be changing API in the stable branches,
whether it's a visibility change or a contract change i.e. behaviour
changed in some subtle way. Unless it's a genuine bug-fix, all
feature changes should be confined to mainline.
In 50x such api changes did caused unexpected breakage for
integrators. In some cases this required code changes. This isn't
ideal at all, and I think it's something the API tooling will help us
with. If the API tooling says we're breaking something in a
maintenance branch, we should really thing hard about whether to make
the change at all!
Yes we not suppose to do that in bug fix mode, but it I don't think
it
was designed to be a good API and we find it out by trial and error. Does it
(API tooling) allow to make something like that as an exception?
Yes, you can add exceptions for given errors which occur, and if need
be this file can be checked in. But this should be heavily
discouraged.
Having a the plugin version number internalize the compatibility
between different releases is just another way of helping extenders
use the functionality safely and increases transparency. Changing API
without up-versioning makes it difficult / impossible for anyone to
know whether the next bug fix release of the cdt platform will
continue to work with extender plugins untouched.
So +1 from me for enabling this.
James
Chris Recoskie wrote:
Wouldn't you rather know you're creating a breakage and deal with it by
adding an exclusion if you need to? Given we're past the freeze, I would
rather turn on the tooling in order to force the conversation to happen
about any such changes. We're going to start ramping down in only a few
weeks.
I haven't detected any actual API breakages. We added some things, hence
the need to upversion to 5.1.0 and give them @since tags, but those are not
API breakages. Most of the changes happen to the internals, which are not
tracked as API. Given that the API errors I found were minor, I don't think
this is a problem, as I think I would have detected breakages if we need to
break things as often as you say, because someone would have broken them by
now in 6.0
Or are we declaring that nothing in MBS is API right now? I don't agree
with that.
===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto
Inactive hide details for Elena Laskavaia <elaskavaia@xxxxxxx>Elena
Laskavaia <elaskavaia@xxxxxxx>
*Elena Laskavaia <elaskavaia@xxxxxxx>*
Sent by: cdt-dev-bounces@xxxxxxxxxxx
04/22/2009 09:46 AM
Please respond to
"CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
To
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
cc
Subject
Re: [cdt-dev] The Great Managed Build API Tooling Fiasco of 2009
As I already said I don't think we should enabled API tooling for this
release because API have to be cleaned up before.
And it has not been done for this release. Committing every small fix
usually results in API extensions for managebuild stuff
(but we should enable it as soon as start 7.0)
Chris Recoskie wrote:
> This seems to have worked out, so unless there are any objections I'm
> going to look at checking in changes to enable this. There have not
been
> many API changes in MBS in this release, so there were not many API
> errors to fix. Mostly missing @since tags.
>
> One thing to note is that the plugin versions will be raised to 5.1.0.
I
> see they are currently at 5.0.100 for some reason.
>
> ===========================
> Chris Recoskie
> Team Lead, IBM CDT and RDT
> IBM Toronto
> Inactive hide details for "Schorn, Markus"
> <Markus.Schorn@xxxxxxxxxxxxx>"Schorn, Markus"
<Markus.Schorn@xxxxxxxxxxxxx>
>
>
> *"Schorn, Markus"
<Markus.Schorn@xxxxxxxxxxxxx>*
> Sent by: cdt-dev-bounces@xxxxxxxxxxx
>
> 04/21/2009 04:15 AM
> Please respond to
> "CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
>
>
>
> To
>
> "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
>
> cc
>
>
> Subject
>
> RE: [cdt-dev] The Great Managed Build API Tooling Fiasco of 2009
>
>
>
>
> The API tooling does not care about how you name the packages. However
> it is important whether the package is marked as internal or not in the
> plugin manifest. Should be easy to fix.
>
> Markus.
>
>
------------------------------------------------------------------------
> *From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
> *On Behalf Of *Chris Recoskie*
> Sent:* Tuesday, April 21, 2009 3:21 AM*
> To:* cdt-dev@xxxxxxxxxxx*
> Subject:* [cdt-dev] The Great Managed Build API Tooling Fiasco of 2009*
> Importance:* Low
>
> Folks,
>
> I've been looking at turning on the API tooling on the MBS plugins.
> However, I've hit a big snag in that many of the internal packages are
> not named correctly (using org.eclipse.cdt.managedbuilder.internal.*
> instead of org.eclipse.cdt.internal.managedbuilder.*) This causes the
> API tooling to think that these packages are public, and it reports
> gazillions of errors on them that should not be considered errors..
>
> My first instinct was to perhaps refactor these packages to use the
> right naming convention, but then we lose the CVS history on them all,
> and this affects a lot of classes :-(
>
> Setting up manual exclusions would be a tedious nightmare, and would
end
> up being an ongoing process that continues whenver someone makes a
> change to the internals.
>
> I've looked to see if there is a way to add additonal rules as to how
> internal packages are named, but I can't seem to find this anywhere.
>
> Does anyone have suggestions/opinions?
>
> ===========================
> Chris Recoskie
> Team Lead, IBM CDT and RDT
> IBM Toronto_______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
------------------------------------------------------------------------
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
