removed unneeded laminas/laminas-hydrator dependency

[driehle]

In #677 the hydrator-related code was removed from this module and moved into doctrine/doctrine-laminas-hydrator. Consequently, in e420353f46c995f1301ff50d31d6bb6e5ebbce90 a dependency to doctrine/doctrine-laminas-hydrator was added.

However, the dependency to laminas/laminas-hydator has not been removed back then, even though code from the Laminas module is never refered to in DoctrineModule. Even in the test cases, where the module Laminas\Hydrator is currently still loaded, no tests refer to that module. Code that is not needed should not be required, as current requirement of ^3.0 prevents users from upgrading to laminas/laminas-hydrator:^4.0.

This PR removes the dependency from composer.json and the module from TestConfiguration.php.

[TomHAnderson]

Thanks for catching this oversight!

[driehle]

@TomHAnderson thanks for the quick merge and release. Shall I provide a PR for the 4.0.x branch as well? Haven't checked this yet, but should be possible there as well.

[driehle]

@TomHAnderson Could it be that something went wrong with your release? https://github.com/doctrine/DoctrineModule/releases shows a 4.1.1 release with a changelog including the change of this PR. However, 4.1.1 has been released November 17th already, https://packagist.org/packages/doctrine/doctrine-module#4.1.1. Did you overwrite the old changelog instead of releasing 4.1.2?

[TomHAnderson]

Packagist is not a source of truth for this information but let's look at the releases on the repository: https://github.com/doctrine/DoctrineModule/releases

Compare this release date of 9/22/2020 4.1.0 @TomHAnderson TomHAnderson released this on Sep 22, 2020

with https://packagist.org/packages/doctrine/doctrine-module#4.1.0 4.1.0 2020-06-20 21:36 UTC

What's going on there? I'm not saying you didn't find an issue but what you found isn't an issue with the releases for this repository.

[driehle]

@TomHAnderson Maybe there is a misunderstanding in regards to tags and releases on Github and how they relate to versions published on Packagist. First, I would like to disagree on your statement that packagist is not a source of truth in this regard. For users of DoctrineModule packagist is the only source of truth. Installing doctrine/doctrine-module will give 4.1.1 currently:

/test # composer init --name=test/test --type=project -n
Writing composer.json
/test # composer require doctrine/doctrine-module
Using version ^4.1 for doctrine/doctrine-module
./composer.json has been updated
[...]
  - Installing doctrine/doctrine-module (4.1.1): Extracting archive
[...]
/test # grep hydrator vendor/doctrine/doctrine-module/composer.json
        "doctrine/doctrine-laminas-hydrator": "^2.0.2",
        "laminas/laminas-hydrator": "^3.0",

As you can see, version 4.1.1 still contains the references to both doctrine/doctrine-laminas-hydrator and laminas/laminas-hydrator. Now why is this? Looking at https://packagist.org/about#naming-your-package it says:

Managing package versions

New versions of your package are automatically fetched from tags you create in your VCS repository. The easiest way to manage versioning is to just omit the version field from the composer.json file. The version numbers will then be parsed from the tag and branch names.

Looking at the tags of your repository, see https://github.com/doctrine/DoctrineModule/tags, we can see ade5281 has been tagged as 4.1.0 on June 20th and f9cf098 has been tagged as 4.1.1 on November 17th. Those are the information that packagist refers to. Consequently, you have released 4.1.1 in November.

Now, the Github releases as in https://github.com/doctrine/DoctrineModule/releases are just some syntactical sugar. They extend git tags by offering maintainers to enter a a name and an arbitrary text for a git tag. This is a nice feature, as you can enter a changelog there. However, Github releases have nothing to do with the package versions you are releasing on packagist. Therefore, as soon as you create a tag, that version will be released on packagist. There is no need for having a Github release.

Could it be that the tag 4.1.1 was created by accident withouth the intention to actually make a release? Nevertheless, I think you will need to make a 4.1.2 release now by tagging the latest commit from the 4.1.x branch, which is 6cdce23.

[driehle]

@TomHAnderson push