commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [primitives] Package layout strategy
Date Wed, 15 Oct 2003 22:12:23 GMT
While I disagree with some of the history described, I believe that the
thrust of the argument here is correct. Code must be released or it dies.

We currently have no agreement, design or code for 'new improved
primitives'. So the current code should be released. And looking back at the
status/history, 1.0 is fair.

Stephen

(My recollection of history/checking suggests that the primitives code was
not in [collections] at 2.0. It was at 2.1, however it did not use the
wrapper object design.
http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg10050.html
indicates a discussion that caused the primitives code to miss 2.1, due to
the rewrite to use wrapper objects and a tight 2.1 timescale. Unfortunately,
no subseqent release took place.)


----- Original Message -----
From: "Rodney Waldhoff" <rwaldhoff@apache.org>
> 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
>


---------------------------------------------------------------------
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