search

squizlabs / PHP_CodeSniffer

PHP_CodeSniffer tokenizes PHP files and detects violations of a defined set of coding standards.
BSD 3-Clause "New" or "Revised" License
10.67k stars 1.48k forks source link

Incorrect bug links in changelog #1378

Closed MarkMaldaba closed 7 years ago

MarkMaldaba commented 7 years ago

Hi there,

Most issues seem to be reported/managed on Github now, but the changelogs on the pear.php.net download page are linking the ticket numbers to tickets on pear.php.net instead. This means that you get very random results if you follow the ticket links!

For example

Fixed bug #622 : Wrong detection of Squiz.CSS.DuplicateStyleDefinition with media queries

instead of

Fixed bug #622 : Wrong detection of Squiz.CSS.DuplicateStyleDefinition with media queries

This needs to be fixed for existing changelog entries as well as for any new releases.

gsherwood commented 7 years ago

My changelogs are all plain text on PEAR. PEAR is creating those links and there isn't anything I can do about them.

MarkMaldaba commented 7 years ago

Oh - that's annoying! I'm sure there's something you can do, though. How about using the word 'issue' instead of 'bug' for the Github ones, to stop the auto-linking from kicking in?

gsherwood commented 7 years ago

I could change it, but I'd rather not change the way the changelogs read. I've stopped linking to the PEAR notes quite a while ago because I have very little control over them.

MarkMaldaba commented 7 years ago

It is confusing, though, as some of the numbers still refer to tickets on pear.php.net, whilst others refer to Github. If you know what you're doing you can probably work it out by the size of the number, but it is pretty counter-intuitive. Personally, I think it would read better if you distinguished between the two ticketing systems somehow, regardless of the auto-linking issue.

MarkMaldaba commented 7 years ago

Plus 'issue' is the terminology that Github uses, and 'bug' is the terminology that PEAR uses, so it makes sense to use the correct term in the relevant context.

MarkMaldaba commented 7 years ago

Hi @gsherwood - just checking you saw my above comments, as you closed this ticket rather hastily.

I don't know how much work it is to update the existing release notes (which would be the best outcome, and would help make the web better!), but I think that at the very least you should adopt this approach for all future releases, to stop more confusing links being incorrectly generated.

gsherwood commented 7 years ago

I'm not going to change the release notes. This is how I format bug fixes for all products I work on and I moved away from the PEAR bug tracker years ago.

MarkMaldaba commented 7 years ago

A bit of an exaggeration - last closed bug mentioned in release notes was July last year: https://pear.php.net/bugs/bug.php?id=21050

Maybe you could ask for the auto-linking to be disabled for this package?

Given this project is all about standards and best-practice, I would have thought you would be more opposed to generating bad links which break the web and cause confusion.