Peter Donald wrote:
>
> At 11:12 19/4/01 -0400, Berin Loritsch wrote:
> >-1 for all the reasons outlined in my other email. We need to make sure
> > that Avalon is not only Modular, but that it isn't fragmented either.
> > It's a fine line to walk--and I think that this should be revisited
> > when JSR-111 has it's first public deliverable.
>
> Well it is probably best to look at use case. As I have said before most of
> my uses of the framework part do not need *anything* out of excalibur
> (except maybe CLI package). The framework is just that - framework -
> completely independent of any arbitrary components created using said
> framework.
If you don't need it, don't use it. Simple.
> What benefit to our users does including the components provide?
Tons. It means that they don't have to reinvent the wheel if they don't
want to. It means that they have examples readily available of the
framework in action. People are basically lazy, and won't bother looking
in another project (even if it is associated) so they will start implementing
their own version of things before they realize that they are wasting or
have wasted time on something that works just as well.
> >I think the timing is bad for this kind of move, because the ramifications
> >can't possibly be completely thought out yet.
>
> agreed - but I am reluctant to beta-ize before doing this.
Why is that? All I am saying is go beta with the components in the jar.
We can then discuss the ramifications, so that for a _distant_ release
we will revisit this.
> >There is already a Jakarta
> >Commons project, and creating a competing project that is Avalon focussed
> >doesn't entirely make sense.
>
> Commons won't accept any of the Avalon components because they are
> "tainted" ;)
That's their loss :P
Really though, I don't think that we should keep fragmenting.
> >The package separation of interface and implementation IMO is
> >enough at this time.
>
> Thats a misconception - we don't do this at the moment. We separate between
> components and framework but interface and implementation sit side-by-side.
I stand corrected. That is what I meant in my head, although I didn't
write it correctly...
> >Let momentum build up around Avalon framework with the Components in
> >the Excalibur package--and when we have more developers we can revisit
> >this.
>
> Put it this way - I want to be able to build AvalonFramework-4.0b.jar and
> place it in C2 CVS. It should not be updated until we release next version
> of framework (ie stable release or RCs if needed)? Can you guarentee that
> you will not modify any code in the excalibur package for that long
> (possibly 4-5 months) ? I doubt it - hence the separation.
Put it this way - I want to be able to build AvalonFramework-4.0b.jar and
update with bugfixes as they come.
Our versioning system should be one like this:
Major number change = structuring or major shift of focus
Minor number change = feature additions
Micro number change = bug fixes.
That way we have a regular release schedule. In that approach, this release
would be Avalon API 4.0b. Bug fixes releases should be Avalon API 4.0b1, b2,
etc.
I don't mind a 3 month release cycle if we are dealing with bug fixes or new
features. I do mind a 3 month release cycle if we are dealing with major
version changes.
When I see a package that has been inactive for a year, then I assume it is
dead and not maintained. When I see a package that has moderate changes
whether they are bug fixes or feature additions (i.e. new components) then
I am comforted to know that the project is maintained, but relatively stable.
Don't get me wrong, the way we are reorganizing Avalon framework is good,
and I like it. I think that being too radical in our changes for a framework
causes more damage than good.
To be honest, I would have a real problem if we didn't go beta because
you didn't get to remove excalibur into a new CVS. According to all the
feedback, noone agrees with the move--so why do it? And why punish those
of us who want beta and stability because we don't have a separate CVS?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
