# PHP Outreach Project (Was: Re:  Make primitive type names reserved words (Was: Re:  [RFC] 5.4 features for vote (long)))

- Thread: https://externals.io/message/53865
- Original archive: https://news-web.php.net/php.internals/53865
- Started by Richard Quadling on 2011-07-11T10:47:38+00:00
- Messages: 1
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #53865 — Richard Quadling — 2011-07-11T10:47:38+00:00

URL: https://externals.io/message/53865#53865

> 
> > […]
>
> Even the php5 versions of Horde? That's rather bad given the so strong
> and loud warnings we gave about using common names w/o namespace, by
> the time of the date problem.

Do we need a sort of out-reach program here? Something that will be
more active in announcing the various potential BC changes that are
going to happen in PHP?

Rather then just having the projects/leaders/developers pull from our
various sources, we (as in the PHP group) actively subscribe to THEIR
lists/FB/twitter/etc.

If this is feasible and supported, I think that any BC we introduce
needs to have support to give details on workarounds. In some cases,
this could be as simple as renaming a class/function/method/etc. In
other cases, more work dependent upon the actual project.

I would recommend only pushing of BC info. New
features/enhancements/etc. that are non-bc (from our perspective and
research), should not be pushed. This means that if I (as a third
party developer) get the call from PHP saying "We will be breaking
classes called string!" I really really need to do something about it.

It may be a pull list is fine/enough, but I guess we already have
these and yet modern projects are still not preparing themselves.


-- 
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea