This will allow the sniffs to have a lower phpcs requirement allowing them to easily be used outside of the MediaWiki code sniffer environment more easily (such as along with other sniffs)

the main codesniffer repo can then stay locked at its super strict code sniffer version :)

This should probably wait until after the GSOC project working on the code sniffer stuff!

Some of the discussion:

8:26 AM <legoktm> Because basically mw-cs *does* depend upon the upstream version
8:26 AM <legoktm> 2.6.0 is currently the only non-broken version
8:27 AM <addshore> legoktm: but surly 2.5 is also not broken? I mean we are using it now right...?
8:28 AM <legoktm> addshore: it is broken, and we have one of the rules commented out in ruleset.xml right now
8:28 AM <legoktm> addshore: and the only reason I did that was because we had to push out the short array mw-cs version
8:28 AM <addshore> legoktm: oh, and thats fixed in 2.6? which rule?
8:28 AM <legoktm> https://github.com/squizlabs/PHP_CodeSniffer/issues/897
8:28 AM <legoktm> yes
8:29 AM <addshore> cool and yes thats in 2.6, okay cool, I switch it to ~2.6 then?
8:29 AM <legoktm> because when they update sniffs and stuff, patches start failing
8:29 AM <legoktm> like the updated indent sniff
8:30 AM <addshore> bah ~2.6.0 for now then
8:30 AM <legoktm> composer will pull in the latest version it can use, and bam, CI starts failing becaues upstream put out a new version
8:30 AM <legoktm> uh, even point releases have broken, their HHVM testing isn't that great
8:30 AM <addshore> its just super annoying if that ruleset is being used with other custom sniffs that also depend on CS
8:30 AM <legoktm> which is why we came to the conclusion to just pin
8:30 AM <legoktm> what I don't understand is what's the need to use 2.6.0?
8:31 AM <legoktm> like, it's better and we should migrate to it asap, but that we can do that in a way that doesn't require making maintaining mw-cs a pita
8:32 AM <addshore> well, as far as I could see the only reason we were still using explicit versions was a s a result of T100544 :P
8:32 AM <addshore> as prior to that we were requireing ~2.0
8:33 AM <legoktm> that was what started it yeah, but I didn't bother filing bugs for all the other breakages I think
8:33 AM <addshore> so if we update to 2.6.0 we should uncomment the currently commented out sniff right? and staying on 2.5.0 means it stays as is?
8:33 AM <legoktm> yes
8:36 AM <legoktm> why is fixing on specific versions such a bad thing?
8:37 AM <addshore> because its a package requiremenet and not require dev!
8:37 AM <legoktm> so?
8:38 AM <addshore> so if another package has the mw code sniff as a require-dev and also something else that depends on codesniffer (a different version) maybe some other custom sniffs you wont be able to install
8:39 AM <legoktm> oh, people want to use other custom sniffs?
8:39 AM <addshore> yeh, so trying to include more versions is going to make life easier
8:39 AM <addshore> but if they are all broken that sucks but we should try and add more flexability moving forward!
8:40 AM <legoktm> I suppose the proper way to deal with that would be to split our custom sniffs into a package with a laxer codesniffer requirement, and have the mw-cs package depend upon specific codesniffer and MW custom sniff versions?
8:40 AM <addshore> ooooooohh
8:40 AM <addshore> yeh codesniffer and codesniffer-sniffs
8:40 AM <addshore> that would likely be the best solution...
8:41 AM <legoktm> BUT
8:41 AM <legoktm> since we're having the gsoc project start real soon now, I don't want to deal with moving things around until after the summer
8:41 AM <addshore> yeh fair :P