PHP5 only sure .. E_STRICT?

Hi, I am a lazy bastard so I am just quoting an IRC discussion (with the lines removed that did not relate to my question): [23:02] <lsmith> So is there any hope on getting some defined rules on how things become E_STRICT? [23:02] <lsmith> people are going nuts about php5 only E_STRICT compliance [23:02] <lsmith> but currently it seems like a runnin target, that means are chasing minor php releases [23:03] <helly25> lukas bla [23:03] <helly25> things that are going to be dropepd or changed or alike in later version become E_STRICT [23:03] <lsmith> imho with the first release of a new major version E_STRICT must not be changed until the next first release of a new major version [23:04] <lsmith> in that first release we throw E_STRICT notices for anything that has been marked as deprecated since the last first release of a new major version [23:05] <andrei> yeah the lists are slow [23:05] <helly25> bla [23:06] <helly25> the argument is there should be no change whatsoever [23:06] <lsmith> ? [23:06] <lsmith> please elaborate on "no change whatsoever" [23:07] <lsmith> is E_STRICT something we hope people actually use on their development boxes? [23:07] <lsmith> or is it more like a code analyzer, that you run now and then on your code [23:07] <SaraMG> Yes [23:07] <SaraMG> E_STRICT for dev [23:08] <lsmith> SaraMG: well if i am supposed to enable it on my dev box [23:08] <lsmith> then it cant change within a major version [23:08] <SaraMG> eh? [23:09] <lsmith> the point is .. if E_STRICT changes with a major version, then it becomes useless for anyone that deploys their projects on more than a single php version [23:09] <lsmith> which is 95% of the php world [23:09] <SaraMG> You don't deploy to a dev box [23:09] <SaraMG> You deploy to a prod box [23:09] <lsmith> so if we keep adding to it .. it will quickly drive you nuts during developmenbt [23:10] <SaraMG> Dev with E_ALL | _ESTRICT. Run in production with 0 [23:10] <lsmith> the point is ... if i am deploying to several different minor php releases [23:10] <lsmith> then i cannot turn on E_STRICT on my dev box [23:10] <lsmith> period [23:10] <lsmith> the way things are now [23:11] <SaraMG> Do you deploy to dev boxes? [23:11] <lsmith> SaraMG: please listen to me [23:11] <lsmith> we keep adding features, that do not exist in previous releases [23:11] <SaraMG> I am, and I don't understand. [23:11] <lsmith> so if we deprecate the old features, and make them E_STRICT [23:12] <lsmith> it means that either i disable E_STRICT during development [23:12] <lsmith> or that i forget about supporting any previous php release with my code [23:12] <SaraMG> or you filter out the strict errors which you know that you don't care about. [23:12] <lsmith> sure [23:13] <lsmith> then we need to make it easy to filter these out [23:13] <lsmith> by being able to configure E_STRICT notices to start from a specific php version [23:13] <scoates> set_error_handler() -- but that's not as easy as you want. [23:14] <lsmith> so you can say: give me all E_STRICT notices starting from php 5.0.5 [23:14] <lsmith> scoates: custom error handler will mean that i need to parse the error messages [23:14] <lsmith> that seems beyond cludgy [23:14] <lsmith> but SaraMG, helly25 .. is the issue now clear? [23:16] <scoates> .. it's no easier for PHP to keep track of when things were introduced, internally, though [23:19] <lsmith> well i dont know how E_STRICT works, but right now its useless for the bulk of the php development community [23:19] <lsmith> we are sending them on a wild goose chase [23:25] <lsmith> am i seeing things that are not there? regards, Lukas