Re: Re: Re: [PEAR-BUG] Req #2099 [NEW]: Internationalised Error Strings

> On Wed, 11 Aug 2004 21:56:54 -0400, Davey <davey@xxxxxxx> wrote:
> > Cipriano Groenendal wrote:
> > >>can we use a beta package as a dependcy?!
> > >
> > > Yes, you can, however no package should have a more stable state then
its
> > > dependancies.
> > > Can't call yourself `stable` if you depend on an Alpha API,
afterall...
> > >
> > <snip />
> > Thats not true. Assuming the user has no *direct* access to that Alpha
> > API through YOUR package, then it shouldn't matter. If the alpha API
> > changes, just change the package that depends on it. The end-user is
> > still depending on your same stable API...
> >
>
> If you want to put it that way, any release is stable in the sense
> that it won't change. If you make your package dependancy for a
> *specific* release of another package, then, yes, I would say you can
> set your package stable even if the dependancy is not. The problem
> lies when the user upgrades that package. AFAIK, the PEAR installer
> will upgrade it just fine without checking the dependencies of the
> other installed packages. (Correct me if I'm wrong.)
>
> So not only would require an RFC for how you can use them, it requires
> a change to the pear installer, which is hard to get done.
>
> If this goes through, it also means that as soon as a new release is
> made of your dependant package, you should immediately update your
> package and make another release. If you don't, you effectively stop
> the user from upgrading the dependant package (and forcing them to
> keep bugs and such, making their system non-stable).

My point exactly.

If it's depending on a package that's still Alpha, you don't know for sure
the API won't change, so you'd have to make it a dependancy to a specific
version of that package, to make sure it won't get upgraded to a new API.
Making a requirement to a specific version will assure you have the same API
still, but if a bugfix release is made you need a new release aswell to make
sure you have those. Neither case is a good solution, so the best option,
IMHO, would be to not make any dependancies on unstable packages, and if you
do, to not exceed the state of the dependancy...

Cipri

-- 
PEAR QA Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php