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. 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/ >> >> -- Clebert Suconic
