Added metadata option

[blargism]

The semantic versioning documentation allows for a metadata option to be appended to the end of a version. The format "#.#.#-rc.0+meta.tags" is a valid version format and useful in multi-deployment scenarios.

[eddiemonge]

How is this different than using prereleaseName?

[blargism]

That was my first go-to actually. However, prereleaseName is only added when you run grunt bump:pre. This is correct behavior since a pre-release tag should only be present when it is an actual pre-release. The bit I added is actually lined out in the semantic versioning spec section 10.

[eddiemonge]

What are you using the metadata tags for?

[blargism]

We have the fairly common use case of multiple similar but not identical deploys of the same software for different clients. Each client will need minor changes to the software so numbered versions do not appropriately indicate the true identity of the deploy. The numbered versions help indicate the core software involved and these meta tags will help us understand if they are the core or client specific.

Having this present in our version makes the version fully informative and machine readable, which we hope to assist with the need to clearly identify deployments and may potentially facilitate automation.

[blargism]

Here is an example:

core version: 1.1.0 (supported currently) pre-release version: 1.1.1-rc.0 (supported currently) client specific version: 1.1.1+initech.production (proposed change) this list is by no means exhaustive

The last version indicates that it's the 1.1.1 release deployed to the "initech" client in a production capacity. This helps us track where the application is as far as features and bug fixes, as well as any client specific tweaks that have been made. All of those things can be nicely tagged in version control and easily referenced in various other places like change logs, the UI, and technical communications.

[eddiemonge]

Why have an array? I think a string should be sufficient

[blargism]

It supports both actually. The array allows for more code flexibility within the grunt file in my opinion. I'm by no means married to the idea. I put it in because string concatenation isn't super awesome in JavaScript and Arrays are much easier to .join() in a semantically proper way according to the spec.

[blargism]

Actually, now that I think about it for a second I did have a specific reason for an Array. The spec indicates that metadata be separated by a . which is easier to enforce in Arrays than with a string+regex.

[eddiemonge]

The array makes it more complex though. The array concatenation could be done outside of this.

[blargism]

Well, I mildly disagree, but only mildly.

I believe the Array is actually in line with the design of the rest of the plugin. The plugin controls the formatting of the version string pretty tightly. The spec for metadata calls for dot concatenated alphanumeric strings. If we use an Array we can enforce that spec clearly, without arrays we leave that in the hands of the user. The user has no queues from the code and we are depending on them to RTM. That rarely happens unless they run into problems. In this case I think the complexity actually serves to provide clarity on how things work.

And as I said earlier, a string is also supported.

If you are insistent that a string is more in line with the plugin's design I'm fine with that. I will close this pull request and create another.

[eddiemonge]

I'd prefer a string as its more clear whats going on. The format can be enforced with a regex test (probably should do anyway, here and the rest of the places that explicitly take a string as the version) that grunt fails if its not correct. Having an array or string requires more checking or more code branches

[blargism]

I'll close this request and make another with those changes.