[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    Re: [DISCUSS] Move Apache.NMS project to Git
From:       Timothy Bish <tabish121 () gmail ! com>
Date:       2017-02-22 17:10:31
Message-ID: fe8d8edd-94a4-3b5d-2555-03b831b7b5a4 () gmail ! com
[Download RAW message or body]

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
> <christopher.l.shannon@gmail.com> 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 <tabish121@gmail.com> 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 <dkulp@apache.org> wrote:
>>>> On Feb 21, 2017, at 9:11 PM, Jim Gomes <jgomes@apache.org> 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
>>>>> dkulp@apache.org - 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/

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic