Re: [pde-ui-dev] Re: PDE API tooling

[Peter Steinfeld <psteinfe@xxxxxxxxxx>]

Thanks, Darin.

With respect to detecting changes in
plug-ins when the source doesn't change, it doesn't sound like you're planning
to address the use case I would like addressed.  You state --

The summary is that we detect this problem as a binary
incomatibility.

Here's more detail on why that doesn't
help.  The big picture is that I'm producing a series of releases.
 For each release, I'm producing daily builds, each of which is a
candidate for testing.  I need the version numbers of the plug-ins
in the daily builds to change when their built contents has changed.  Let's
say I just shipped release 1 which contains plug-in A version 1.2.3.a and
plug-in B version 7.8.9.b where plug-in B depends on plug-in A.  Now
I start work on release 2, which has not yet shipped.  The developers
of plug-in A make an API change and change its version number to 2.0.0.
 The developers of plug-in B notice this and make appropriate changes
to have it depend on version 2.0.0 of plug-in A.  Daily builds are
still happening, and everything is working.  Now the developers of
plug-in A change the value of a static final variable that's used by plug-in
B.  This is a breaking API change.  However, the plug-in A team
has already changed their version number to advertise that they're no longer
compatible with the version of plug-in A that shipped in the previous release,
so they don't change the version number of plug-in A.  The next daily
build builds both plug-ins A and B.  This newly built version of B
has different contents than the previous version even though its full version
number, including the qualifier, hasn't changed.

This is the situation I would like to
detect.

Darin Wright <Darin_Wright@xxxxxxxxxx>
Sent by: pde-ui-dev-bounces@xxxxxxxxxxx

01/16/2008 11:57 AM

Please respond to
"Eclipse PDE UI developers list." <pde-ui-dev@xxxxxxxxxxx>

To	pde-ui-dev@xxxxxxxxxxx
cc
Subject	[pde-ui-dev] Re: PDE API tooling

I'm posting some more good questions... 

> 
> I have some questions about the use cases for the API tools.
> 
> One of the things that's very important for our development teams
is
> that they correctly follow the Eclipse version number rules for 
> their plug-ins as they submit changes to the daily builds.  We
> currently have a tool that we run as part of our builds to check 
> this.  It takes as input the current built plug-in, the last
shipped
> built version of the same plug-in, and produces a status and a 
> report.  The status is good if the version numbering rules were
> correctly followed and bad otherwise.  The report contains more
> detail about the violations in the case of bad status.  Are you
> planning to produce a similar tool?  Note that, for use in the
> build, we require batch mode operation.  Of course, any tool
that 
> the build uses should also be available to developers in the IDE.

Yes, we are planning to provide support in the IDE to detect invalid plug-in
version numbers. This feature is based on the deltas produced when comparing
plug-ins. The delta engine is designed to run without OSGi and could be
invoked by a build/releng process. We also plan to incorporate this into
the Eclipse build process to produce simple reports. We also intend to
leverage the support to report invalid package export version numbers.
The related bug reports are: 

        https://bugs.eclipse.org/bugs/show_bug.cgi?id=213019
        https://bugs.eclipse.org/bugs/show_bug.cgi?id=215073

> 
> Along these lines, there's an obscure but important special case of
> version number violations that we need to implement for our builds.
> There are times when the built content of a plug-in changes even 
> though its source hasn't changed.  We need to be able to detect
this
> and, at the very least, report that it happened.  One way for
this 
> to happen is if plug-in A contains the definitiion of a final 
> variable and plug-in B uses that variable.  Plug-in A changes
the 
> value of the variable, and plug-in B gets rebuilt with the new 
> version of plug-in A.  This newly built version of plug-in B
is 
> different from its previous version.  However, since we base
the 
> version numbers of plug-ins on the versions of the source files, the
> version number of B didn't change.  I have two questions about
this 
> situation -- 
> Are you planning to detect this case in any of your tooling?

This is an interesting case. We do detect when a constant field changes
value and report this as a binary incompatibility problem. That is, if
you change the value of a constant, this breaks clients that reference
the constant. (I can't recall if this is only for static finals, or finals
in general - Olivier will be able to tell us).

So, I would consider such a change a "breaking API" change. In
this case plug-in A must increment its major version segment (described
here: http://wiki.eclipse.org/index.php/Version_Numbering). Plug-in B in
it's original form should still require a lower version range of plug-in
A. In order to work with the new version of A, B needs to be re-built and
update its required version range for A. I would expect that B also needs
to note this change by incrementing its maintenance segment (although,
John Arthorne is the expert on version numbering and might be able to shed
more light on this). B has not changed any API, but the new version of
B only works with the new version of A, and does not work with the previous
version of A. 

> If we were to write a tool to detect this, is there any code in the
> current API tooling that we could leverage to solve this problem?
 
> The only solution that we've so far conceived is to do a binary 
> compare of the two versions of the built plug-in, filtering out the
> volatile information in the process of doing the compare.
> 

The summary is that we detect this problem as a binary incomatibility.
We would also detect/report that plug-in version numbers need to be incremented.
Our tooling does not currently detect the lower bound of A that B is compatible
with. We would like to enhance the tooling to do this in the future.

Darin Wright_______________________________________________
pde-ui-dev mailing list
pde-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-ui-dev