Allow the project to define versioning.

[jamesiarmes]

Issue by glennpratt Monday Oct 19, 2015 at 16:04 GMT Originally opened as https://github.com/acquia/cloud-moonshot/issues/12

---

Let the project determine what version the current source code represents.

Not sure how you would want to implement this, but parsing output of script/version could work or override something in bin/environment.

[jamesiarmes]

Comment by askreet Monday Oct 19, 2015 at 17:06 GMT

---

One use case would be projects like alerts-api which use git-commit based versioning.

[jamesiarmes]

Comment by askreet Monday Oct 19, 2015 at 17:07 GMT

---

The current model has the store action on the ArtifactRepository, which means we'd be overwriting each others development builds if the file said e.g. "0.1.2". Might be a non-issue if we use deploy-code for development builds, as it passes a timestamp and user based version string, maybe we fall back to the file for default which is used for release builds in Jenkins.

[jamesiarmes]

Comment by glennpratt Monday Oct 19, 2015 at 17:16 GMT

---

I'd also be fine with saying providing a unique version is part of the contract (or you can opt-in).

I used this:

git describe --tags --dirty=-`date +%s`-$USER

[jamesiarmes]

Comment by askreet Wednesday Oct 21, 2015 at 15:20 GMT

---

I think a VersionProvider makes sense, though I'm not sure how to keep the current default behavior. Currently we use Thor, and the version-name argument is required for build-version and deploy-version. We could switch those functions to varargs and validate 0 are given when a VersionProvider can infer the version (we ask it), and validate than 1 is given when the VersionProvider is NullVersionProvider, or something.

[jamesiarmes]

Comment by askreet Wednesday Oct 21, 2015 at 15:21 GMT

---

Perhaps VersionStrategy, UserProvidedStrategy and GitTagsAndBranchesStrategy.