commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <rwaldh...@apache.org>
Subject Re: [primitives] Package layout strategy
Date Wed, 15 Oct 2003 16:06:41 GMT
On Tue, 14 Oct 2003, __matthewHawthorne wrote:

> You may feel that the primitives code was "passed over for release for
> no particularly good reason", but the community disagreed.  There were a
> lot of reasons discussed, and many developers chimed in with their
> opinions.  The consensus seemed to be that the primitive code should be
> moved to another project.  I think we should accept it and move on.

Just as I wrote, my comments were in reference to the 2.0 release of
commons-collections.  I stand by them.  It may be interesting for you to
go back into the archives and look at that debate.  If I remember
correctly, the lack of a list of doubles was considered a show-stopper at
that time.

Curiously, the "community" (of one, possibly two) that blocked the release
at that time contributed significantly more opinions that code,
documentation or support, and has since disappeared from jakarata commons
entirely.

> The fact that unreleased code is being used in production somewhere
> shouldn't necessarily categorize it as releasable.  It seems that code
> has to stand on its own merit along with other commons code and releases
> to be considered as such.  My wording may be a little confusing; my
> point is, just because you're using the code in production doesn't mean
> that commons should release it.  It seems to be more community oriented.

The fact that the code in question is old, stable, 100% tested and
features a design and implementation long informed by real world use
suggests that this code is quite releasable.

> There are some packaging issues that have yet to be solved, releasing
> the current [primitives] code as v1.0 may cause some deprecation and
> backwards compatibility headaches if changes occur (and it seems that
> they will.)  I think the best decision is to release the current code as
> 0.1, and think about possible improvements and additions for 1.0.

Let's consider the history of this code base:

The code in question was initially developed for and by another project,
which in turn contributed the code to commons-collections (following an
informal and unanimously positive vote).

This code was stable and release-ready at the time of the
commons-collections 2.0 release.  For reasons substantially weaker than
the ones we're debating now, it was decided to hold back that code for the
2.0 release, forcing the donating project and user community to rely upon
snapshot builds in the interim.

Fast forward nearly a year.  We're finally gearing up for a 3.0 release of
commons-collections, and it is agreed (after much debate) to move this code
to a distinct commons component.  It is not suggested that changes to the
existing code are warranted, nor that the code isn't release ready, but
the move is made simply in the interest of maintaining a more focused
scope.  This entails more delays and less backwards-compatibility.

Now it is suggested that it is not reasonable to release this old, stable,
100% unit tested, well field tested, informed-by-real-world-use code
without adding a host of new types that don't yet exist and are of
hypothetical utility.  This will result in additional delays and even less
backwards-compatibility.

> I think the best decision is to release the current code as
> 0.1, and think about possible improvements and additions for 1.0.

I agree, except what you're calling 0.1 should be 1.0.  Calling the
*release* 0.1 with the thought that that somehow absolves us from
following a backwards-compatible deprecation policy is simply flawed.
Adding a host of new types whose design is uniformed by real-world use,
whose implementation is significantly newer than the existing code, and
that has never been used outside of internal unit tests and thinking that
is somehow more stable or more reasonably considered a 1.0 release is
similarly flawed.  This is an insufficient reason to further delay a 1.0
release of this code base.

Projects that regularly disregard the interests of their contributors and
regularly and repeatedly inconvenience their early-adopters risk losing
them.  Jakarta Commons in general, and this code base in particular, has
already suffered at the hands of folks who've neither contributed to nor
used the code in question, but are more than happy to chime in with
superficial design decisions.

The existing code is release ready, and as such should be released. Let's
haggle about a fresh color for the bike shed for the 2.0 release.

- Rod <http://radio.weblogs.com/0122027/>

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


Mime
View raw message