We're using non-specific version constraints for all of our dependencies. This causes unnecessary problems for very minimal gain.
With the current process, if I need to update one dependency, I edit the composer.json, run composer update, and not only does it update my dependency, but all others that have new releases that satisfy our version constraints.
Now I have to create a patch that includes any dependency that got updated, which is not ideal considering that the one issue I post to now has to be seen by anyone who is working with an updated dependency. Alternatively, I could selectively add just the package that I needed changed, but then the composer.lock will be pointing to updated versions of other packages that I didnt include. I guess I could hand edit that, but no thanks.
I propose that we should *never* use fuzzy version constraints. Specific stable/beta/alpha tags should be our first choice, and then if we need changes that haven't made it into a tag yet, we use the specific git hash for that commit.
This way, if I need to update one dependency in the composer.json, only that dependency is changed when I run composer update. This will be much easier for both contributors and reviewers.
This patch changes all the version constraints to the latest tags that fit within our previous version constraints, with the exception of easyrdf where I just specified the latest hash. This patch also brings a bunch of updates to dependencies because that's what happens when you run composer update currently. Hopefully this can be the last monster dependency updating patch of its kind.