Also, if each NMS sub project has a different version than maybe it would actually be better to have a separate repo for each one. That might be a pain to manage though but would make the releases independent.
On Wed, Feb 22, 2017 at 10:16 AM, Daniel Kulp <[email protected]> wrote: > > > On Feb 21, 2017, at 9:11 PM, Jim Gomes <[email protected]> wrote: > > > > I guess I didn't explain the requirements clearly. Tagging is not the > > solution. This is about automatically injecting the revision of the > source > > code that was used to build the product. For example, let's say the > > Subversion repository is at revision number 18634. I am building > > Apache.NMS version 1.7.0. When I run my build, it will automatically > > produce an assembly with the embedded version number 1.7.0.18634. That > > last number can't be a hash. > > Why can’t it be a hash? Or at least the git short hash? That’s the > exact revision id for git so if that is what the purpose is, then that is > what should go there. > > > > If I were to commit any change at all (not > > necessarily creating a tag or branch, just a change), then the repository > > would increment to 18635. If I build again, it would produce Apache.NMS > > 1.7.0.18635. Automatically. This way there is no confusion as to what > > exact revisions went into creating that assembly, and I have a > reproducible > > build. > > And the has accomplishes the same thing if the goal is a reproducible > build. > > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > >
