Re: [PEAR-DEV] BC breaks: Cache_Lite, PHP_Documentor

[email protected] (Chuck Burgess)
Newsgroups php.pear.dev,php.pear.qa
Message-ID <[email protected]>
Given that phpDocumentor is an app rather than a library, does this change
actually pose a risk of "breaking a user's code"?  I'm inclined to think
this is a safe enough change, albeit one that might highlight to the user
that a php.ini setting should be reevaluated.

Or, would a preferable alternative to the symptom (deprecated function) be
to just switch to using ini_set()?
CRB


On Tue, Aug 24, 2010 at 12:37 AM, Matthew Fonda <[email protected]>wrote:

> On Mon, Aug 23, 2010 at 8:14 PM, Daniel O'Connor
> <[email protected]> wrote:
> > To fix the following:
> > http://pear.php.net/bugs/bug.php?id=17774
> > http://pear.php.net/bugs/bug.php?id=17690
> >
> > requires a BC break for PHP4 users with magic quotes on.
> >
> > I propose:
> >  1. Tag/Branch the code at this point, fix the issue on trunk for both
> > packages
> >  2. Put in the world's loudest "we just did a BC break" changelog
> messages
> > in the relevant releases
> >  3. Publish that on the package homepage too.
>
> This is explicitly prohibited by PEAR standards [1]. A user may miss
> the BC break notice, and find their code unexpectedly broken after
> upgrading a stable package. People should not be using PHP4 still, but
> unfortunately some are and we can't break things for them.
>
> I think this gets back to the unresolved discussion previously brought
> up about old packages [2]. I like the "middle ground" idea Daniel
> proposes, but as Helgi notes changing package channels is currently
> not supported, so maybe we can find some other solution that still
> allows us to move away from PHP4. Some PEAR usage stats on PHP
> versions would definitely be useful to see.
>
> [1] http://pear.php.net/manual/en/rfc.version-naming.standard.php
> [2] http://marc.info/?l=pear-dev&m=127280685832232&w=2
>
> Best Regards,
> --Matthew
>



-- 
CRB
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.