On 02/22/2017 11:47 AM, Clebert Suconic wrote:
I think it would be simpler to have the releases aligned as it creates
a DLL Version Hell (that's an actual term on Windows/ActiveX) when you
update versions dependencies.
I can clearly see this made up scenario in a real life / customer scenario:
"Hypothetical: "NMS.ActiveMQ is dependent on NMS 1.1 as it has a bug
fix on the NMS, while NMS.Stomp 1.3 still depending on NMS 1.0 as it
didn't need a certain bug fix... etc.. etc..."
Aligning these versions would be easier for users IMHO. But that's a
separate discussion.
It doesn't really work that way in the NMS client library releases and
it isn't necessary given the way the release artifacts are built and
versioned.
On Wed, Feb 22, 2017 at 11:37 AM, Christopher Shannon
<[email protected]> wrote:
Thanks for the clarification Tim, I missed your message from yesterday. So
yeah in that case if we do the migration then it makes sense to me to just
create a separate git repo for each one.
On Wed, Feb 22, 2017 at 11:23 AM, Timothy Bish <[email protected]> wrote:
On 02/22/2017 10:47 AM, Christopher Shannon wrote:
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.
They already are in separate repos now.
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS/
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
ache.NMS.ActiveMQ/
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Ap
ache.NMS.Stomp/
etc.
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
--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/
--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/
