apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@rkbloom.net>
Subject Re: documented 1.0 showstoppers
Date Thu, 03 Jun 2004 19:29:17 GMT
On Thu, 3 Jun 2004, Greg Stein wrote:

> On Thu, Jun 03, 2004 at 01:35:06PM -0400, rbb@rkbloom.net wrote:
> > On Thu, 3 Jun 2004, Justin Erenkrantz wrote:
> >...
> > > Can we fix it in 2.0?  Sure.  No reason that a 1.0 release prevents that.
> > > And, we might be able to fix it in 1.1, but it depends how we handle the
> > > specifics.  However, 1.0 does not have to be perfect!
> >
> > It can't be fixed in 1.1, because the whole API needs to be re-thought.
> > As for why I haven't fixed it yet, I don't have the time.  I'm really
> > sorry, but a new job and a new child kind of do that to you.  I'm not
> > asking 1.0 to be perfect, but I am asking that we not release an API that
> > we know for a fact does not work.  That just isn't honest to our users.
> As Justin pointed out, the users seem to be just fine with it sitting in
> there. *TODAY*. So why would they suddenly be unhappy with it tomorrow?

I disagree, strongly, and we have already heard from one user.  However, I
won't argue this anymore.  I have highlighted the problem, and proposed a
solution.  I won't have time in the near future to execute the plan.  I
don't think it is honest or fair to our users to release a production
quality release of a portable library with a bug that we know makes it
non-portable.  My arguments are out there now, I'll not try to support 1.0
with such a glaring hole, but I will try to fix it in a later release.
However, the fix will require an API change.  I will be _very_ upset if
the API isn't allowed to change because 1.0 shipped with this bug.


View raw message