On Thu, 3 Jun 2004, Greg Stein wrote: > On Thu, Jun 03, 2004 at 01:35:06PM -0400, [EMAIL PROTECTED] 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. Ryan
