Re: [Clirr-devel] code format

[Simon K. <si...@ec...>]

On Tue, 2004-06-15 at 03:57, bob mcwhirter wrote:
> Just curious, is it like iDarwin/aDarwin?  They track API changes, I think.

It looks like iDarwin was intended to enforce rules like:  
  * classes in pkg X must not reference classes in pkg Y
This might be useful to verify, for example, that datamodel classes
never reference UI classes.

However this is not the intent of clirr. The problems clirr intends to
solve are:
(a)
I released version 1.0 of this library last year. Now I'm about to
commit a patch. Am I sure that this patch is binary compatible, ie users
of this library can upgrade without recompiling?
(b)
I'm about to release a new version of library X. I need to write release
notes - but what changes *have* I made to the API?
(c) 
I'm a user of library X, and there is an upgrade but their release notes
are useless. What changes have there been to the library API? And are
they binary compatible (ie I can just install the new lib) or will I
need to recompile my source code?

Obviously clirr won't display *all* changes; some behavioural changes
can be implemented without any API change. However it will detect most
of them. The JDiff tool (jdiff.sourceforge.net) also attempts to cover
some of this. But it does so by using javadoc doclets to analyse the
source. Clirr analyses the jar files instead, hopefully making it much
easier to use (and faster). And jdiff doesn't highlight binary
incompatibilities, or provide an ant/maven plugin that can autodetect
patches which break binary compatibility.

I hope I've got this description right - I'm sure Lars will correct me
if I've missed something.

Cheers,

Simon