On Tue, 28 Oct 2014 17:49:55 -0700 (PDT)
guru prasad <gupr1...@gmail.com> wrote:
[...]
> Now my question is if the project version is 1.2.3.4
>
> then I can put this 1.2.3.4 in the archive version so I can see it on
> the runtime but I also want to be able to correlate the version of
> the config file. The config file has Dev, QA, QA perf, PRD
>
> Now when I deploy I want to be able to deploy with 1.2.3.4:1.2 (1.2
> being the version of Dev config file) something like this.
>
> Am I completely off track? Not sure how to individual keep track of
> the 4 config files in the config project folder so that I can deploy
> dev changes separately with dev version number, QA with QA number
> etc.,
It's not really clear what exactly do you want to achieve.
You can't have Git somehow automatically use/track/modify/apply those
version numbers because Git does not know anything about them.
But I suppose you can leverage Git in one way or another to help you
maintaining these version numbers.
What comes to my mind is:
1) Have two special files in your repository: one containing the
project version and another containing the config version.
Make the archive generation tool read them but not include them
into the archive it generates.
Normally, these files should be empty or contain some template
values, like "A.B.C.D" and "X.Y" respectively, then, during the
release cycle of a particular S/W revision, the branch tracking this
would receive two technical commits: one populating the app version
file and another one populating the file with configuration version.
2) Use tags of special format understood by the archive generation tool.
Again, during the release cycle of your software product, once the
devs release their code, tag it using something like "app-v1.2.3.4".
Then, when another set of changes is done to prepare a particular
configuration tag the resulting commit with something like
"conf-v1.2".
When generating the archive, use
git describe --tags --match 'app-v*' <commit>
to obtain the nearest "application version" tag, then
git describe --tags --match 'conf-v*' <commit>
to obtain the nearest "config version" tag, parse out version numbers
from then and construct the resulting version.
You can then tag <commit> with a combined tag, say, simply
"v1.2.3.4:1.2" to be able to easily locate this version afterwards
when a support request comes in.
3) Just use branches named after version numbers.
Say, when you're about to start a release cycle of a particular
version of your software, fork a branch named "v1.2.3.4" off the
point the dev team blessed as ready for release.
When you need to apply certain configuration to it, fork another
branch off "v1.2.3.4" and name it "v1.2.3.4:1.2".
I'm not sure I fully understood your requirements but at least all
that might fuel your imagination.
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
