Nicer formatting for development versions

[morozov]

If an installed dependency has a development version constraint (say 3.0.x-dev), the result looks like:

3.0.9999999.9999999-dev@f9844cfd7179b1e279c0a78e41d96cb710858763

As far as I understand, these 9ths come from composer/semver and are mere implementation details. If one uses it in the --version output as suggested in https://github.com/Ocramius/example-symfony-cli-usage/pull/4, the output looks bloated.

A nicer output might look like in sebastianbergmann/version: 3.0@f9844cf. Having commit hash in the displayed version string implies non-release version, so the -dev suffix is not needed in this case. Not sure if it's possible to reliably determine the minimal hash length without git binary and repo at hand.

[theofidry]

From what I see we just need to replace 9999999.9999999-dev by 0-dev right?

[Ocramius]

This package doesn't care about "nice" formatting: it will always smash together the composer "detected" vs "source" versions.

On 3 Jun 2017 12:30, "Théo FIDRY" notifications@github.com wrote:

From what I see we just need to replace 9999999.9999999-dev by 0-dev right?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Ocramius/PackageVersions/issues/43#issuecomment-305966541, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJakMozlES-ZyDKa4xbFsW-Bj_-WpQgks5sATW3gaJpZM4Nu6o2 .

[theofidry]

@Ocramius but that makes this package hardly usable, having yet another micro-package wrapping it just for it would be silly. What's more is that this "detected" is a Composer internal thing, it doesn't really make sense from the user POV.

[Ocramius]

Why so? The package is supposed to give raw version information to tools that need it (usually to decide when any version change happened).

On 3 Jun 2017 13:06, "Théo FIDRY" notifications@github.com wrote:

@Ocramius https://github.com/ocramius but that makes this package hardly usable, having yet another micro-package wrapping it just for it would be silly. What's more is that this "detected" is a Composer internal thing, it doesn't really make sense from the user POV.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Ocramius/PackageVersions/issues/43#issuecomment-305968159, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJakPbuEbXXiimIIYUTDV_4T1GpnzM5ks5sAT5KgaJpZM4Nu6o2 .

[theofidry]

If the goal is to give raw information, then maybe it makes sense to keep it as it is.

To extend more on my use case, I was thinking of adding this package kinda like shown in https://github.com/Ocramius/example-symfony-cli-usage/pull/4 to display the command version. But there's two issues with that:

• Right now this Composer internal thingy is exposed (which is what this issue) is about
• You always get the SHA of the commit

If both may make sense in the context of giving raw information, they hardly make any sense for users in the case above [command version].

You could always argue that having one helper method or two is enough to deal with those two issues, but I would find it annoying to have to do it for each command application and having a micro-library do deal with it would make me feel like I'm doing JS. And given how trivial they are, I think it would be a nice addition to this package.

[Ocramius]

If both may make sense in the context of giving raw information, they hardly make any sense for users in the case above [command version].

No, if I run a cli app I want to see that kind of info too.

On 3 Jun 2017 13:23, "Théo FIDRY" notifications@github.com wrote:

If the goal is to give raw information, then maybe it makes sense to keep it as it is.

To extend more on my use case, I was thinking of adding this package kinda like shown in Ocramius/example-symfony-cli-usage#4 https://github.com/Ocramius/example-symfony-cli-usage/pull/4 to display the command version. But there's two issues with that:

• Right now this Composer internal thingy is exposed (which is what this issue) is about
• You always get the SHA of the commit

If both may make sense in the context of giving raw information, they hardly make any sense for users in the case above [command version].

You could always argue that having one helper method or two is enough to deal with those two issues, but I would find it annoying to have to do it for each command application and having a micro-library do deal with it would make me feel like I'm doing JS. And given how trivial they are, I think it would be a nice addition to this package.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Ocramius/PackageVersions/issues/43#issuecomment-305968908, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJakGHiG9ITWlZZEJtvZTy2VJU6k_GSks5sAUI4gaJpZM4Nu6o2 .

[theofidry]

No, if I run a cli app I want to see that kind of info too.

If it's a tagged version this hardly matters and most CLI apps currently don't display it (and don't want to display it)

[Ocramius]

Yeah, no, that's just useless nitpicking: show the entire thing or waste 30s of your life to explode() it.

On 3 Jun 2017 15:41, "Théo FIDRY" notifications@github.com wrote:

No, if I run a cli app I want to see that kind of info too.

If it's a tagged version this hardly matters and most CLI apps currently don't display it (and don't want to display it)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Ocramius/PackageVersions/issues/43#issuecomment-305975808, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJakKwA4QMxFyGv9d1qS7IRBaHBRp6tks5sAWJugaJpZM4Nu6o2 .

[theofidry]

It's a one function call that makes the difference between having something that just works as you want right away and something you have to tweak for whatever reason.

Having something like 5.0.9999999.9999999-dev@69c4f49ff376af2692bad9cebd883d17ebaa98a1 is just way too verbose and look alien, whereas 5.0.0-dev@69c4f49 would be a good compromise. Then if you really want to nitpick to display another variant like 5.0.0-dev or something, fair it might not be worth it to have it in this library.

But well, maybe we disagree to agree.

[Ocramius]

Not gonna happen here: this package gets the detected version as-is, with no additional processing to avoid any kind of of loss of information or too eager assumptions.

That said, closing here: version string will stay as-is, while nicer parsing and representation should be delegated to packages like composer/semver.

The purpose here is to cache full version information without any runtime I/O, nothing further.

[morozov]

The purpose here is to cache full version information without any runtime I/O, nothing further.

It explains the "won't fix" resolution.

The package is supposed to give raw version information to tools that need it (usually to decide when any version change happened)

To understand the purpose of the package better: the version output contains both version and the commit hash. What's the intended use case where both of them are needed? If it's for tooling/automation, commit hash will be enough for detecting changes. If it's for UI, the hash is only needed for non-tagged commits.

[theofidry]

Update your example and avoid complains :P

On Sat, 3 Jun 2017 at 19:34, Sergei Morozov notifications@github.com wrote:

The purpose here is to cache full version information without any runtime I/O, nothing further.

It explains the "won't fix" resolution.

The package is supposed to give raw version information to tools that need it (usually to decide when any version change happened)

To understand the purpose of the package better: the version output contains both version and the commit hash. What's the intended use case where both of them are needed? If it's for tooling/automation, commit hash will be enough for detecting changes. If it's for UI, the hash is only needed for non-tagged commits.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Ocramius/PackageVersions/issues/43#issuecomment-305993346, or mute the thread https://github.com/notifications/unsubscribe-auth/AE76gf2sfWP19pkuIQwKlDEruKv1Ujj3ks5sAac6gaJpZM4Nu6o2 .

[Ocramius]

Update your example and avoid complains :P

PR PLOX

[Ocramius]

What's the intended use case where both of them are needed?

Sometimes the source doesn't contain the hash, and composer generates a version that is to be used. Sometimes the composer version is a branch reference that needs a complementary version.

Therefore, "composer computed version" + "source version" is a relatively reliable approach.

[Jean85]

If anyone is still interested, I've released a really small package to do this: https://github.com/Jean85/pretty-package-versions