On Wed, Mar 31, 2010 at 9:49 AM, Philip Olson <phi...@roshambo.org> wrote: > (d) Write "Future PHP Release" or similar until we know (seems okay) > > I lean towards (d) for most cases. Thoughts?
I'd also prefer D since it is the easiest to search & replace once decisions are made. I think however that instead of Future PHP Release, which sounds really vague and timeless, I'd suggest deciding upon a name that everyone uses to talk about the next php, the obvious PHP.Next seems to be almost a standard now, we could make it more phpey with \PHP::Next or something, but I don't mind too much either way. This is still a bit vague and timeless, but it sounds cooler and it sounds like it's coming next, not "once upon a time in the future". Next has the problem that everything that gets committed to trunk might not make it into Next, but I believe once we have a clear release plan we can start converting PHP::Next tags into 5.4 or whatever, and leave out the features that didn't make it. For deprecations, I think this is great because it scares people a bit while things are shady, and it might motivate some to get their butt moving off old code. For new features, it might of course disappoint, but then should we really be documenting those months/years before it is decided they will be in a release? It sounds quite ridiculous in retrospective when looking at all the PHP6 unicode stuff, it's in the docs yet might never come to see light as it was documented. It's both a loss of time for documenters and disappointing to people that were looking forward to it for maybe years. For deprecated I think saying "DEPRECATED in 5.3, REMOVED as of PHP::Next" sounds like the best plan to be complete about all versions, but that seems to be what's in place on the safe_mode page. Cheers, Jordi
