Drop forceful loading of annotations

[greg0ire]

Since doctrine/annotations 1.10, autoloading is used when everything else has failed. Using registerFile() has been deprecated in favor of that later on.

[mlocati]

This is a breaking change and shouldn't have been included in a dot release...

We have this line in our code:

\Doctrine\Common\Annotations\AnnotationRegistry::registerFile('doctrine/orm/lib/Doctrine/ORM/Mapping/Driver/DoctrineAnnotations.php');

And it now breaks the execution with an E_COMPILE_ERROR error:

Doctrine\Common\Annotations\AnnotationRegistry::registerFile():
Failed opening required 'doctrine/orm/lib/Doctrine/ORM/Mapping/Driver/DoctrineAnnotations.php'

[greg0ire]

I had no idea this was used directly like that outside the package itself, so to me it wasn't a breaking change and was therefore OK to include in a minor release. It is mentioned in the UPGRADE.md though, so I guess I should have looked better. Let me know if you think reverting this will be beneficial to your users or if it is not worth it considering you have a fix at concretecms/concretecms#11185

[mlocati]

Many projects have hundreds of dependencies, and checking the changelog of all of them is not feasible.
That's why we have semver: breaking changes (like removing publicly accessible methods and files) should be done only in new major versions.
Yep, we fixed the issue, but I was speaking in general, and I don't think that publishing a new version fixes the issue, users simply have to live with it now 😉

[derrabus]

Semver does not protect you if you bypass the public API of a package. This package's file structure is not part of its public API. If you include specific files directly you are basically on your own.

[greg0ire]

Also, technically everything is a breaking change. For instance, a change to the README can be a breaking change if you do the following in your project:

if (md5(file_get_contents('vendor/doctrine/orm/README.md')) === 'some_hash_here') {
    // do stuff
}

Another example:

So if everything is a breaking change, nothing is, and it's up to us maintainers to decide what's a breaking change and what isn't. We try to listen though, but you'll have to admit the lecture on semver wasn't necessary, and that the attitude some of your contributors have towards us is not exactly going geared towards understanding and listening: concretecms/concretecms@18b8216

[mlocati]

Semver does not protect you if you bypass the public API of a package.

What's this document?

[greg0ire]

Likewise, if you think we're in the wrong, the right thing to do IMO is not to point it out and attempt to embarrass us in the process. Just state what your argument plainly.

Example:

Granted, files are not usually part of the public API of a package, but the documentation of doctrine/annotations made an exception at some point about this particular type of files.

What's so hard about being nice to your fellow maintainers? And even, for the interest of your project, how is this going to make us want to care about your issues?

[mlocati]

When exactly have I been so rude?

[greg0ire]

When exactly have I said you were?