semver issue

[maps82]

The bundle seems not to accept the version "1.2.3-foo-bar.1", which is a valid semver.

According to http://semver.org/#spec-item-9 "-" is a valid character in a pre-release string.

I just silently creates "1.2.3-foo" out of the git tag.

[shivas]

It is bug in underlying library issue and fix: kherge-archive/php-version#11

That actually brings us to question how we should proceed with this issue, as that library is deprecated (not supported/developed) any more.

One of the options would be to bring in that library into the bundle itself, but that may require major version bump of this bundle. (if namespace changes).

Any other ideas?

[mdriessen]

I've looked into this because I also noticed the library is deprecated. The best replacement I found is https://github.com/nikolaposa/version which provides a very similar versioning interface and seems actively supported.

I've made some changes in https://github.com/mdriessen/versioning-bundle/tree/semver and it seems to work as expected. What do you think about these changes?

Before I make a pull request I want to write some tests so I can compare how the new library behaves on different kind of version numbers compared to the old one. Not sure where to start that though. Any suggestions are appreciated.

[shivas]

@maps82 i pushed few hours ago 2.0.0-alpha, can you try it and see if it solves your issue?

[maps82]

Hi! Thanks for the update, 2.0.0-alpha works fine for my above example 👍

[maps82]

Do you plan to release 2.0.0 soon? Thanks!

[mdriessen]

I don't know how fast @shivas wants to release version 2.0.0, but I think some more improvements can be made. The VersionBumpCommand contains to much logic which should be moved into a service. Also I don't know if it's necessary to use the verbose and very verbose output levels because running composer install --verbose doesn't seem to increase the output level of the command. Maybe this can be fixed in the ScriptHandler, else I would just output everything because it's useful information and not really for debugging purposes.

Another thing that bothers me a bit is that when using the application_version parameter as a Twig global, you must also put the parameter in either the parameter.yml or parameter.yml.dist. This makes the InitialVersionProvider a bit redundant since the command won't even run with the Twig global defined and the parameter.yml being empty. This should be in the documentation or maybe it's an option the use the VersionsManager service to provide the parameter instead (not get it from the providers as currently in the docs). But I don't know how much the overhead is, probably not much as it's just constructing some classes.

If you want to try out this alpha release just put "shivas/versioning-bundle": "dev-2.0.0-alpha" in your composer file.

[shivas]

Well, I'm open for new pull request and fixing some parts, as bumping major version opens hands to implement anything BC breaking. I don't feel urge to release it ASAP or something, at least you now have version that is working, as @mdriessen mentioned you can use "dev-2.0.0-alpha" as version or even add exact commit.

For my taste, I would love it to be more covered in tests if we already started testing.

InitialVersionProvider was created to handle specific edge case when there is no other handlers available/supported.

From my point of view, deploying this versioning bundle if you don't use any specific handler makes little sense anyway.