Skip to content
This repository has been archived by the owner on Jan 1, 2020. It is now read-only.

Update version number as part of build process #356

Open
GeeH opened this issue Jul 1, 2016 · 12 comments
Open

Update version number as part of build process #356

GeeH opened this issue Jul 1, 2016 · 12 comments

Comments

@GeeH
Copy link

GeeH commented Jul 1, 2016

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

Suggestions.

@Ocramius
Copy link
Member

Ocramius commented Jul 1, 2016

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

@GeeH
Copy link
Author

GeeH commented Jul 1, 2016

Banning @Ocramius for blatant advertisment.

@GeeH
Copy link
Author

GeeH commented Jul 1, 2016

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

@Ocramius
Copy link
Member

Ocramius commented Jul 1, 2016

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
Copy link
Author

GeeH commented Jul 1, 2016

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

@stijnhau
Copy link

stijnhau commented Jul 9, 2016

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
Copy link
Contributor

@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
Copy link
Contributor

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

@samsonasik
Copy link
Contributor

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

@weierophinney
Copy link
Member

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
Copy link
Member

@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 👍

@weierophinney
Copy link
Member

This repository has been closed and moved to laminas/laminas-skeleton-installer; a new issue has been opened at laminas/laminas-skeleton-installer#3.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants