Composer ranges operator bug

[krystalcode]

Using "php": ">=5.3.3" in this composer.json file.

https://github.com/krystalcode/feature-toggle/blob/master/composer.json

Result is current php 5.6.6, locked to 5.6.5.

https://www.versioneye.com/user/projects/54e0ed6d271c93aa120001ce

[krystalcode]

I manually triggered a re-parsing of the project and this was resolved. All looks good now. I assume that this would automatically get fixed next time I pushed something on the repo.

So how does this work - whenever a new version of a library is released, the dependency file needs to be re-parsed? Why do you keep a Locked version f the library for the project, while it's not locked in actuality? Would it not be simpler - and also more accurate - to display whether the latest version of the library is accepted based on the dependency definitions? This way this problem with having to re-parse the project whenever a new version of any of the libraries is released would be avoided.

First time using VersionEye so I may not understand exactly how this is set up.

[Robert Reiz]

@krystalcode Thanks for the additional comment. By default your project gets re parsed once a day, if you didn't changed that in the project settings. It does not get re parsed after each git push. That would require a git hook integration.

The "locked" column shows what would be the version based on the dependency definition. I agree that column name is a bit misleading, because it might be that the numbers in the composer.lock are different. Any better ideas for the column name?

Alternatively you can also monitor your composer.lock file. If you use the GitHub/Bitbucket integration to flip the switch beside a composer.json file then VersionEye will fetch the corresponding composer.lock file as well and create a multi file project. That way you have both (composer.json & composer.lock) in the same project view.

I'm kind of blind for UX issues at VersionEye, simply because I build it. But I'm open for UX improvements.

[Robert Reiz]

@krystalcode I just deployed another background job. If VersionEye finds a new version it updates all related project dependencies from custom user projects like yours. That brings the desired behaviour.

Your input on the user interface is still very much appreciated! Just open a another ticket for UI improvements.

[Robert Reiz]

@krystalcode It looks to me that it works half way :-) If a new version is detected the related project dependencies are updated via a mongodb batch update. That updates the "current" number. The "locked" number has to be recalculated for each project dependency one by one. It seems that the 2nd step did not happen for your project. Not sure why. I have unit tests for both steps but things are getting strange on high scale. Maybe the database pointer was running into a timeout because there are A LOT of project dependencies which reference to PhpUnit and php-src. I have to think about that, how to make it more robust on a higher scale.