use samsonasik/package-versions to get version

[samsonasik]

samsonasik/package-versions is a backported version of ocramius/package-versions that support php 5.6. /cc @Ocramius

[michalbundyra]

@samsonasik it is not the same as before.
Now we have zend-mvc version, before it was (should be) ZendSkeletonApplication version.

I don't know if the constant version in the library is important (useful) at all.
It could help investigate issues (in ZendSkeletonApplication) if we know what version of ZendSkeletonApplication was used by developer. For me, we should have fixed "Zend Framework 3" as we had for ZF2.

[samsonasik]

unfortunatelly, the packageversions can't detect its version of project currently used, as if i use zendframework/zend-skeleton-application (not part of vendor), it will return like 999999.dev, probably @Ocramius can give some input about it...

Warm regards,

Abdul Malik Ikhsan

Pada 21 Jul 2016, pukul 21.59, webimpress notifications@github.com menulis:

@samsonasik it is not the same as before.
Now we have zend-mvc version, before it was (should be) ZendSkeletonApplication version.

I don't know if the constant version in the library is important (useful) at all.
It could help investigate issues (in ZendSkeletonApplication) if we know what version of ZendSkeletonApplication was used by developer. For me, we should have fixed "Zend Framework 3" as we had for ZF2.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Ocramius]

That simply means "dev-master@dev"

On 21 Jul 2016 18:33, "Abdul Malik Ikhsan" notifications@github.com wrote:

unfortunatelly, the packageversions can't detect its version of project
currently used, as if i use zendframework/zend-skeleton-application (not
part of vendor), it will return like 999999.dev, probably @Ocramius can
give some input about it...

Warm regards,

Abdul Malik Ikhsan

Pada 21 Jul 2016, pukul 21.59, webimpress notifications@github.com
menulis:

@samsonasik it is not the same as before.
Now we have zend-mvc version, before it was (should be)
ZendSkeletonApplication version.

I don't know if the constant version in the library is important
(useful) at all.
It could help investigate issues (in ZendSkeletonApplication) if we know
what version of ZendSkeletonApplication was used by developer. For me, we
should have fixed "Zend Framework 3" as we had for ZF2.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#371 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakED2pXpk29Sta-K0p9wknLu4Po8uks5qX59FgaJpZM4JRzxQ
.

[samsonasik]

@Ocramius any suggestion of what it should be then?

Warm regards,

Abdul Malik Ikhsan

Pada 22 Jul 2016, pukul 02.12, Marco Pivetta notifications@github.com menulis:

That simply means "dev-master@dev"

On 21 Jul 2016 18:33, "Abdul Malik Ikhsan" notifications@github.com wrote:

unfortunatelly, the packageversions can't detect its version of project
currently used, as if i use zendframework/zend-skeleton-application (not
part of vendor), it will return like 999999.dev, probably @Ocramius can
give some input about it...

Warm regards,

Abdul Malik Ikhsan

Pada 21 Jul 2016, pukul 21.59, webimpress notifications@github.com
menulis:

@samsonasik it is not the same as before.
Now we have zend-mvc version, before it was (should be)
ZendSkeletonApplication version.

I don't know if the constant version in the library is important
(useful) at all.
It could help investigate issues (in ZendSkeletonApplication) if we know
what version of ZendSkeletonApplication was used by developer. For me, we
should have fixed "Zend Framework 3" as we had for ZF2.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#371 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakED2pXpk29Sta-K0p9wknLu4Po8uks5qX59FgaJpZM4JRzxQ
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Ocramius]

999999.dev@SHA1YADDAYADDA is correct. It will print 1.2.3@SHA1 for tagged versions

[samsonasik]

\PackageVersions\Versions::getVersion('zendframework/skeleton-application') return 9999999-dev@89c54ddbed3c6a17bc20fbc74218d7d60efaa8f4, what $packageName should be passed then?

[Ocramius]

Probably 'zendframework/zend-mvc' ;-)

[samsonasik]

I did that :P

[samsonasik]

\PackageVersions\Versions::getVersion('zendframework/zend-mvc') is ok to get full version with hash included

[weierophinney]

This is a hard one.

With ZF1/2 (until 2.5), Zend\Version\Version::VERSION was available, and denoted the framework version. The move to the constant in the skeleton was prompted by the fact that the only singular version we can look at is the skeleton itself.

However, as @samsonasik has noticed, PackageVersions works on the dependencies, but not the application — and even if it did, it would change immediately, as the version then becomes that of the application, not the skeleton!

The point we need to discuss is: is the information worthwhile?

I'd argue that, to an extent, it is: it tells us where the application began, and most times we're getting that, we're working with developers new to composer and/or ZF; if they report this particular version, it helps us understand that we're likely working with newcomers, and whether or not they started with the latest skeleton version.

If that's the case, the only real way we can version is either through a constant in the application somewhere, or one defined in the composer.json (in the extra tree).

Thoughts?

[weierophinney]

Alternate suggestion: we have a collapsible list detailing all components installed, and at which version... which is something that PackageVersions gives us.

[michalbundyra]

In my opinion if we tried limit number of dependencies in the skeleton we should't include any package version here. Also I can't see big advantage of having the constant version number, even if we are working with newcomers we don't know what steps they did before:

• composer install or composer update?
• minimal installation or with optional packages?
• any custom configuration/dependencies?

Installed packages we could get from composer show and maybe we should add it to documentation. If somebody will have issue with base skeleton it means our release is broken, what is quite unlikely (hopefully). I'd remove constant and the dependency (of PackageVersions) and, in case of issue, ask for the list of installed packages (composer show) or/and steps to reproduce the issue.

[samsonasik]

@weierophinney I'm ok with show list of zf components installed, if approved.
@webimpress it is common that user seeing framework version number when they installed the skeleton, so version number show is needed imo.

[samsonasik]

@weierophinney I added list of zf components installed.

[samsonasik]

@weierophinney merge-able now ?

[adamlundrigan]

I'm not a fan of adding it directly into the skeleton as non-dev since it's not aimed at the application the user wants to build...it's a convenience for the developer and for those of us who help them when they run into trouble. Could the package be added to require-dev and still fulfill #356?

As for the UI, maybe this is better pushed over to ZendDeveloperTools? It could have a panel which lists all the installed versions.

it tells us where the application began, and most times we're getting that, we're working with developers new to composer and/or ZF; if they report this particular version, it helps us understand that we're likely working with newcomers, and whether or not they started with the latest skeleton version.

I do agree this would be useful. The developer isn't likely to continually backport changes from newer versions of the skeleton into their existing apps, so the files provided by the skeleton end up being frozen in time while the Composer-provided dependencies do. Knowing what version of the skeleton they started with, then, is a useful piece of information. I'd argue that the starting versions of the skeleton's dependencies aren't, though (eg: is it useful to know that servicemanager was at 2.6.0 when they installed the skeleton but it's at 2.7.7 now?).

Could we instead use composer scripts to cache this information somewhere on install and/or update? The DX around that could be improved by ZendDeveloperTools and/or CLI tooling to display the cached version information.

[Xerkus]

for debugging purposes we can ask output from composer show, otherwise i tend to agree with @adamlundrigan that extra dependencies like this are not really needed in a skeleton application

[Xerkus]

Since no one else decided to move forward with this feature and overall consensus is towards dropping version constant altogether, I am going to close this PR without merging.