Re: todo list (was: Re: [PROPOSAL] lifecycle release)

Berin Loritsch <[email protected]> Wed, 19 Mar 2003 10:29:22 -0500
Newsgroups gmane.comp.jakarta.avalon.phoenix.devel,gmane.comp.jakarta.turbine.maven.devel
Message-ID <[email protected]>
Leo Simons wrote:
> up front, thanks for writing this.
> 
> Peter Donald wrote:
> 
>> On Sun, 16 Mar 2003 10:57, Leo Simons wrote:
>>
>>>> * released components have backwards compat broken haphazardly
>>>
>>>
>>> just in cvs, and they get fixed, too. Having CVS means some 
>>> experiments are
>>> possible!
>>
>>
>> Still no one has fixed the backwards incompatible changes to thread. 
>> It has been a couple of weeks now, a -1 and ... nothing.
> 
> 
> I was under the impression Berin had reverted this (he said so on-list). 
> I'll have a look. In the meantime you should feel free to make the 
> revert yourself IMO.

I reverted the stuff in Cornerstone.  I unintentionally did not revert
the changes in Thread.



>> The only reason why coordinated releases could make sense is if there 
>> is high coupling between components - in which case I would argue that 
>> the components should not be released.
> 
> 
> hmm. Even when there is no tight coupling it makes sense to do extra 
> testing (besides the continuous integration gump affords, and our nearly 
> nonexistent unit tests) on some snapshots. Especially since our gump 
> setup has been broken so long: changes might have crept into the 
> packages which might've broken somewhere else. With the huge size of the 
> avalon codebase, the broken integration, and the limited unit tests, I 
> simply cannot be sure no incompatible changes have been made. Can you?

We also have alot of questions with our users that come up from time
to time.  They are along the lines of "Excalibur Logger doesn't work
with LogKit X because of exception Y".  Instead of finding all the
places where components are not working with each other (because they
are in CVS), we are baselining our product-set.

This fresh start approach allows us to audit what we will support,
and validate that it does not break back compatibility.  That also
means we need to add tests--so any help will be appreciated.