If we did a 2.0, as NMS is an equiv of JMS would it be an idea to add equiv JMS
2.0 methods into NMS.Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: "Heiser, Derek" <[email protected]>
Date: 17/04/2019 18:10 (GMT+00:00) To: [email protected] Subject: RE:
AMQNET-565: .net standard port Yeah, I thought about that and am not opposed to
it. But typically I think of actual API changes in major version changes and,
while the supported frameworks changed, the underlying api surface did not. I
do think moving to 2.x does sort of signal to users that 'breaking stuff may
have occurred'.I'm up for whatever, though.~Derek-----Original
Message-----From: Timothy Bish <[email protected]> Sent: Wednesday, April 17,
2019 12:02 PMTo: [email protected]: Re: AMQNET-565: .net standard
portOn 4/17/19 11:10 AM, Heiser, Derek wrote:> Hello all,>> I wanted to try my
hand at this feature request:
https://issues.apache.org/jira/projects/AMQNET/issues/AMQNET-565?filter=allopenissues
to port ActiveMQ to .Net Standard. I’ve started working on a fork here:
https://github.com/killnine/activemq-nms-api/tree/refactor but wanted some
feedback from contributors before I sink too much time in.>> The current build
(1.7.2) supports .net 2.0, 3.5, and 4.0.>> Net standard 2.0, by default,
supports back to 4.6.1. I’ve looked into supporting multiple target frameworks
(for instance, .net standard 1.2 supports 4.5.1) but there are some pretty
gnarly conflicts (ex: System.Transactions, NUnit 3, serialization attributes)
between even .net standard 1.2 and the latest .net standard.>> My
recommendation would be to treat 1.7.2 as the legacy package and make this
change a 1.8.0 build as a fresh start to support 4.6.1 and above with
netstandard 2.0. I thing we could update the README to explain the support for
earlier frameworks. I totally understand the need to support older platforms,
but I think keeping 1.7.2 around and moving forward ensures we aren’t hamstrung
by the very clear direction from Microsoft that Netstandard is the way
forward.My advice would be to move to v2.0 for the API and any new client
releases of NMS.ActiveMQ (or other already released NMS clients) as that makes
it more clear that fundamental changes in supported .NET SDKs are present as
well as leaving room for breaking API changes etc.> There’s other issues I’d
like to address with the solution > organization but figured this was the
biggest point of discussion > right now…>> I’m on the Slack channel if you want
to discuss off the record 😉>> Thanks!>> Derek Heiser> Follow Us:
Facebook<http://www.qg.com/social1> | > Twitter<http://www.qg.com/social2> | >
LinkedIn<http://www.qg.com/social3> | > YouTube<http://www.qg.com/social4>--Tim
Bish
