Re: [PEAR] Re: PHP_CodeSniffer: Patchlevel updates break our Coding Standards

Well I was offended by the way I was approached and it is unreasonable for
anyone to tell me how to feel.

I also answered the issues of the generic coding standard and versioning in
general. I feel I provided enough information to solve Christian's problem
right now, and to make his standard more future-proof. I don't know how
this can get any more technical. It's a pretty high-level discussion.

Greg


On Thu, Feb 28, 2013 at 9:18 AM, Ferenc Kovacs <[email protected]> wrote:

>
>
>
> On Wed, Feb 27, 2013 at 10:34 PM, Greg Sherwood <[email protected]>wrote:
>
>> Christian,
>>
>> It seem you have misunderstood the purpose of the generic sniffs. The way
>> to use them is to cherry pick the ones you want; not to include the whole
>> bucket of sniffs and then exclude the ones you don't. They are unrelated,
>> and many conflict with each other. So I suggest you swap around to this
>> model and you wont have any problems with the code I release as you will
>> be
>> in full control of your standard.
>>
>> Adding a new generic sniff is not akin to adding a new feature to the core
>> product, and I am quite happy with the way versions are working right now.
>> I haven't had anyone else become confused about it and I always put out
>> plenty of information when I am breaking backwards compatibility, such as
>> the not-so-recent change to the way custom coding standards were defined
>> and the current 1.5 release that rewrites the reporting engine. These are
>> not entire product rewrites (PHPCS still functions in the same way), but
>> they are potential BC breaks for some developers and so I put out RCs and
>> articles to help migrate. I think I'm doing a pretty good job in this area
>> and find your email quite insulting.
>>
>> But I suspect you wouldn't be concerned about versioning at all if you
>> change the way your standard is constructed.
>>
>> Due to the way you've chosen to go about creating your standard, you've
>> obviously been angry for quite a few releases (I add generic sniffs quite
>> often) and decided to vent your frustration by lecturing me on a public
>> mailing list. I'm not sure why you felt this was the best way to
>> communicate with me. Everyone else seems to be able to get in touch with
>> me
>> without feeling the need to include a much wider audience. Next time you
>> think you have a problem with me or any code I maintain, I'd appreciate it
>> if you would come to me directly.
>>
>> Greg
>>
>>
>> On Wed, Feb 27, 2013 at 10:03 PM, Christian Weiske <[email protected]
>> >wrote:
>>
>> > Hi,
>> >
>> >
>> > We've build our own coding standard on top of the Generic and PEAR
>> > coding standards:
>> >
>> > > <ruleset name="NRT3">
>> > >   <rule ref="Generic">
>> > >     <exclude name="Generic.Classes.DuplicateClassName" />
>> > >      ...
>> > >   <rule ref="PEAR">
>> > >     <exclude name="PEAR.Files.IncludingFile" />
>> > >     ...
>> > >   </rule>
>> > >
>> > >   <rule ref="Netresearch" />
>> > >
>> > >   <exclude-pattern>*/ext_emconf.php</exclude-pattern>
>> > > </ruleset>
>> >
>> > With nearly every PHP_CodeSniffer patchlevel release, we had to adjust
>> > our own coding standard because the rules changed.
>> >
>> > Most recently, 1.4.4 added a
>> > > "php files must not contain newlines at the end"
>> > sniff, which meant we had to adjust our standard again.
>> >
>> > PEAR's backwards compatibility[1] rules are very strict, and they are
>> > something I could always rely on. PHP_CodeSniffer seems to have broken
>> > with this model.
>> >
>> > Greg, please use patch level updates for bug fixes, not to introduce
>> > new features. Use feature level updates to introduce them.
>> >
>> > The PEAR rules are basically the same as what's now known as "semantic
>> > versioning"[2] and widly supported.
>> >
>> > x.y.z
>> > - change in x: big changes/rewrite
>> > - change in y: new features level
>> > - change in z: bug fixes
>> >
>> > [1] http://pear.php.net/group/docs/20040226-vn.php
>> > [2] http://semver.org/
>> >
>> > --
>> > Regards/Mit freundlichen Grüßen
>> > Christian Weiske
>> >
>> > -= Geeking around in the name of science since 1982 =-
>> >
>>
>>
>>
>> --
>> Greg Sherwood
>> Chief of Engineering
>> [email protected]
>>
>> Squiz Labs Pty. Ltd. Suite 4, 7 Parkes St Parramatta NSW 2150
>> P  +61 2 9045 2800   W  www.squizlabs.com
>>
>
> Hi,
>
> I couldn't find anything offensive in the original mail, and while I agree
> that maybe sending you a private mail would have been more discrete, but
> your reply seems to be pretty knee-jerk and aggressive imo.
> Could we discuss this on the technical level, putting personal feelings
> aside and without insulting each others?
> Thanks for your understanding and your work on the packages is much
> appreciated! _o_
>
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>



-- 
Greg Sherwood
Chief of Engineering
[email protected]

Squiz Labs Pty. Ltd. Suite 4, 7 Parkes St Parramatta NSW 2150
P  +61 2 9045 2800   W  www.squizlabs.com