In my work as a PHP developer I sometimes get frustrated when I or a teammate gets the "release version" wrong of a library that we use, and a backwards incompatible change gets released under a "minor" or "patch" version bump. This usually causes breaks for the unlucky person who updates the dependencies when, if everybody stuck to true semantic versioning, everything should work exactly as it did before.
I'm working on this proof of concept to help; it analyses proposed changes in a GitHub pull request and gives a breakdown of the types of changes (backward incompatible or no, etc). Based on this it recommends what the next release of the project should be.
At the moment it only works for opensource PHP projects, I invite you to give it a spin on an opensource project you may be working on. Feedback would be hugely appreciated.
1 comment
[ 2.8 ms ] story [ 12.3 ms ] threadIn my work as a PHP developer I sometimes get frustrated when I or a teammate gets the "release version" wrong of a library that we use, and a backwards incompatible change gets released under a "minor" or "patch" version bump. This usually causes breaks for the unlucky person who updates the dependencies when, if everybody stuck to true semantic versioning, everything should work exactly as it did before.
I'm working on this proof of concept to help; it analyses proposed changes in a GitHub pull request and gives a breakdown of the types of changes (backward incompatible or no, etc). Based on this it recommends what the next release of the project should be.
At the moment it only works for opensource PHP projects, I invite you to give it a spin on an opensource project you may be working on. Feedback would be hugely appreciated.
Many thanks!