after updating from ember-cli 2.15.3 to 2.16.0, the version isn't picked up when EMBER_ENV=production is set

You've published your IntelliJ .idea older, presumably unintentionally since it's not in the repo.

For example the following are all valid SemVer Versions and they are not accepted by the helper when the hideSha Option is used. What is worse it breaks the whole app.

• 1.10.0 (Version number with more than one digit)
• 1.0.0-alpha.1 (Version number with a pre-release)

The second example doesn't actually raise an error but it is just stripped from the version (would return 1.0.0).

The reason being that the versionRegExp used doesn't match those cases: /\d[.]\d[.]\d/

Option hideSha was introduced in #36

I have several suggestions:

• Make the matching more robust. I don't even see a reason to use a regex. Splitting on + (the sign used in SemVer to separate build metadata from the rest of the version) should be enough.
• If for some reason something doesn't match return an empty string but don't break the whole app

As long as the hideSha Option is not used everything should continue to work as before so this is not critical. But especially the first issue (not accepting version 1.10.0) will probably lead to some head-scratching when using the Option.

Hi, it would be nice to have an option to show commit date as well.

Most of the nontechnical people prefer to see date & time instead of version or hash.

I was thinking about using ember build date, but that's a bit different from git commit date. Sometimes we do rebuild or we can build out of a week old code so it's not accurate.

What do you think? I could eventually send you PR if that sounds interesting to you.

Thank you,
Ondrej

https://github.com/cibernox/git-repo-version/blob/master/index.js

Just started using this in our app, so thanks 😄

Since the addon defines an initializer that registers the app as an ember library, I was surprised to see that it wasn't listed in the normal library version debug output. After a little digging it appears that initializers run after that method is called, so the app version isn't in the list when it's printed. Not a big deal, but I've definitely found it handy to find the version in the console without opening the ember inspector and clicking the info tab (I used to call Ember.libraries.register in app/app.js directly).

I would have opened a PR, but I can't figure out how to use addon hooks to run code before Ember.Application#init is called. The only thing I could think of was to add an inline script using the contentFor hook, but that ends up violating CSP. Do you have any idea how to do this?

Could y'all release v3.0.0 from master (which includes #39).

Note: it needs to be 3.0.0 because of dropping [email protected] compat.

let me recommend at least logging via ui if something goes wrong. That being said, I think we should actually just explode if package.json doesn't contain version

https://github.com/taras/ember-cli-app-version/blob/master/index.js#L18-L24

I'm thinking about adding ember version:bump command. I'm thinking about using semver library to increment version number by parameter.

Examples

• ember version:bump major - major version bump
• ember version:bump minor - minor version bump
• ember version:bump patch - patch version bump

Before, I do this, I have a few questions:

1. Would you use it?
2. Are you using something now and what?

https://github.com/cibernox/git-repo-version/pull/3/files

Example: 0.10.0+0fbd02d5

This version number caused the regex to not find a match, which made the helper error out and break the consuming app.

Could you elaborate on how you obtain a sha at the end of the version number ? I imagine it's obvious but...

The image in the README.md shows this information, however in reality its not there. This would be very useful!

Latest commit has two tags: v1.2.3 and deploy-production-<sha>

Expected: app version is 1.2.3
Actual: crashes because it tries to apply regex to deploy-production-<sha> tag

When building the app on Heroku for example, there is no .git folder during the build process. This results in version numbers like 1.0.2+ because the SHA commit hash is missing.

Heroku -does- expose the commit hash in a SOURCE_VERSION environment variable that we could tap into in this case.

Any thoughts in how this could be achieved? Perhaps being able to pass in a custom resolver during build could be beneficial?

@rwjblue it might be best to have this live in ember-cli organization at this point. I made you an admin on the repo. Is that sufficient for you to transfer it over?

Feature request. Allow access to the app-version within controllers, components, etc.

Thanks in advance!

The recent blueprint updates and version bumps that are on master need to be released (to go along with [email protected]). Can we get a 3.1.0 released?

Since this is included in ember-cli by default I wonder if you would mind allowing @stefanpenner or myself to publish/release also (I believe we have merge access but not npm publish access)?

/cc @taras @alexlafroscia

The custom config hook in index.js was removed by e30885b, I am not sure how this library can be working at the moment...

I was using ember-cli-build-info before. @elidupuis now dropped support for ember-cli-build-info in favour of ember-cli-app-version.

ember-cli-build-info adds version information to builds as meta tag in index.html and injects it in routes and controllers. Following documentation of ember-cli-app-version it only adds version information to ember inspector. Is there any functionality planed or already implemented but not documented like ember-cli-build-info had?

Currently we have ember-cli/ember-cli-app-version which uses cibernox/git-repo-version which uses rwjblue/git-repo-info. I think this is too much complexity for this problem.

Also I think more and better configuration would be nice for ember-cli-app-version.
Also it seems (#49, #50, cibernox/git-repo-version#9) that we need some configuration.
Ideally I think would be to have some kind of template string the user can provide, to specify which information in which order should be shown. At least we should have a way to display everything provided by rwjblue/git-repo-info.

My suggestion is to remove cibernox/git-repo-version and directly rely on rwjblue/git-repo-info. Then we could allow the user to provide a format function that takes the info from rwjblue/git-repo-info and have a sane default. Also we could provide the prefix, which calculation is currently the most complex thing git-repo-version/index.js does.

something like this looks like a possible solution in my opinion:

formatFunction: ({prefix, sha, authorDate}) => `${prefix}${sha ? `+${sha}` : ''} ${authorDate}`,

any thoughts?

Hi,

It appears that no SHA is displayed when a git tag is present. Is this intended behavior? I'd love to be able to still display the SHA even if there is a tag given that I typically use npm version to update my package.json.

Thanks!

If I trigger build on gitlab, I end up with an artifact which always shows the version + a part of the commit hash like 0.3.4+05bab3e2

If I build locally I get the short version like 0.3.4

hbs:

{{app-version versionOnly=true}}

command is ember build --environment production in both cases

What I noticed is that the builds artifacts differ in their index.html. Both have a meta tag which contains the version information. However the CI seems to populate the version field with data from package.json and the local build seems to use the git tag. The code_version field is identical on both. Just noticed because I was using a new tag but kept the previous version in package.json

Any ideas what might be happening or how to get the short format without the commit hash within the CI build on gitlab?

I'm really confused why the branch is tagged as 0.4 and the package.json is still marked as 0.3.4. Should the new version be bumped and published?

The initial tag support only checked .git/refs/packed-refs, which will only contain tags that have been packed via git pack-refs (see here).

By default tags are stored in .git/refs/tags/ with a separate file for each tag (contents is the SHA).

For underlying support, see: rwjblue/git-repo-info#2

Submitted cibernox/git-repo-version#4 to update locked version. Once @cibernox merge's and releases we need to update git-repo-version here.