Re: [Proposal] LogKit Release Plan

[Peter Donald <pe...@realityforge.org>]

On Sat, 1 Feb 2003 09:59, Noel J. Bergman wrote:
> > > What's your definition of "a while"?  We need a plan for removing them.
> >
> > How about a plan of "We don't remove them". No need to break code on a
>
> whim.
>
> How's about Avalon 5? 

AValon5 refers to framework classes which are on a completely different 
release schedule than logkit and Logkit should never need another major 
version.

> I agree that unless you know what your existing
> client base is using, that you need not break backwards compatibility
> within a major version.
>
> Seems to me that lesson ought to have been learned by now ...

You would think...

Seems silly to break backwards compatability at anytime regardless of 
versioinng unless there is more to gain than is lost by futzing with existing 
users.

-- 
Cheers,

Peter Donald
*----------------------------------------------------*
|  "Luck is the residue of design" -- Branch Rickey  |
*----------------------------------------------------*


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

RE: [Proposal] LogKit Release Plan

["Noel J. Bergman" <no...@devtech.com>]

> > How's about Avalon 5?
> AValon5 refers to framework classes which are on a completely different
> release schedule than logkit and Logkit should never need another major
> version.

AV5 also refers to a container and component packages.

As an aside, I disagree with respect to the release schedule on the
following grounds.

When we release James vX, we release all of it.  There may be classes,
entire subsystems, that haven't changed in ages.  But they are all part of a
single, defined, tagged, supported Release build.

Any project that adopts a piecemeal approach to release management
encounters problems.  This isn't to say that there aren't reasons to do so.
In some cases it makes sense, but it rarely doesn't cause problems, so it
should be avoided when possible.

Yes, someone else can take Frameworks and Components, and write their own
container.  But that is their problem to support.  The Avalon PMC is
responsible for what it ships.

This isn't to say that there isn't a place for releasing supplimental
packages separate from the main release.  But a coordinated approach to code
release should be normative, in my view.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org