Update version number as part of build process

[GeeH]

We need to to this as part of release but I have no idea how.

Suggestions.

[Ocramius]

Somebody backport and maintain ocramius/package-versions for PHP 5.x plz

[GeeH]

Banning @Ocramius for blatant advertisment.

[GeeH]

On a serious note, would you have a problem with this repository having a dependency on ocramius/package-versions @weierophinney?

[Ocramius]

ocramius/package-versions is (purposely) 7.0.x only, but since it's MIT, anyone can just grab it and backport the functionality. As it stands, it's just about removing few type hints and strict type declarations

[GeeH]

It's easier if we just up the requirements of this skeleton application to 7.0.x.

[stijnhau]

That might be true but i think de dependcy on PHP-7 for the default app that 90% of people will start with is just to soon.

[samsonasik]

@Ocramius I forked your ocramius/package-versions and try to make it compatible to ^5.6 in my forked repo ( samsonasik/PackageVersions#1 ) , would you mind to review ?

[samsonasik]

there is a samsonasik/package-versions now! a backport of ocramius/package-versions that support php 5.6 ;)

[samsonasik]

I've created PR #371 for it to use samsonasik/package-versions as backport of ocramius/package-versions that support php 5.6 ;)

[weierophinney]

And... despite having this and related issues open today... I forgot to bump the version when I released 3.0.3 a short bit ago, belying the need for this to be in place.

I'm still unsure how to proceed. The version constant approach does have use cases in terms of us helping understand where to start with a user, but typically the output of composer show will be far more relevant. Having that info in the browser could be useful, particularly for users who are uncomfortable with the command line and/or composer, but means an extra package that serves no purpose once the template is replaced.

In many ways, I think I'd rather just drop the version constant altogether. Thoughts?

[michalbundyra]

@weierophinney

In many ways, I think I'd rather just drop the version constant altogether. Thoughts?

As I remember correctly the idea to have the constant was for easier investigating issues with the skeleton, to help resolve reported issues. It is going to help only with issues only in the skeleton, not in dependencies, as I've mentioned already over a year ago #371 (comment) and suggested there dropping the version constant.

Removing the version constant from the skeleton - YES from me 👍