With NServiceBus v7 almost 4 years old, NServiceBus v8 being in the workings for quite a while and seeing the last wave of Core beta-2 updates about a month ago, is there an indication when to expect version 8 to be available that Particular can provide? I’m aware of the “no timeline commitment” approach. I am not asking for a specific date but more of an idea where v8 is at and wherever customers that have to invest into significant upgrades (such as from .NET 3.1 to .NET 6) should hold off and wait for NServiceBus to bundle it up, or better not wait.
Hi Sean,
As you wrote yourself, we generally don’t commit to a specific release date, so I can’t answer your question precisely. There are still a few open items that we want to get done before the release of version 8.0, as we believe they provide valuable benefits for our users. If you want to get familiar with the latest state of version 8, the recently released v8 beta 1 packages are available for everyone interested on our public MyGet feed (https://www.myget.org/F/particular/api/v2/package). This can be a great way to quickly check for potential issues for an upcoming upgrade.
I am not asking for a specific date but more of an idea where v8 is at and wherever customers that have to invest into significant upgrades (such as from .NET 3.1 to .NET 6) should hold off and wait for NServiceBus to bundle it up, or better not wait.
.NET Core 3.1 and .NET 6 are listed as supported on our supported platforms documentation so I don’t think there is any strong reason to hold back from updating target frameworks already.
With NServiceBus v7 almost 4 years old
btw. version 7.7 of NServiceBus has been released just a month ago and we try to make new features available to currently available major versions of NServiceBus whenever possible 
Cheers!
Hi Tim,
Thank you for the quick response. I’m afraid it wasn’t clear enough what I’m after.
The question is not wherever there are new features coming or it’s OK to run on .NET 6. The actual question is about timeframe for NServiceBus 8 for clients that are going through the upgrade to .NET 6 due to the very clear and timed cadence set by Microsoft. Looking at NServiceBus 8 API changes such as Cooperative cancellation, which is a fantastic addition, and asking wherever they should hold off for a few weeks/couple of months to benefit from the support for CancellationToken propagation or forget about it and stick to .NET 6 with NServiceBus 7 until the next big upgrade, where NServiceBus 8 would be included.
Just to give an idea, upgrades that require rigorous validation of the changes throughout the entire code base that are impacted by NServiceBus API changes is not a trivial upgrade for many organization, as you probably know. It has to be a coordinated effort. And those exercises are not frequent or at the development team’s discretion.
Hope shedding light from the other side helps to see the perspective.
Thanks.
Hi sean,
I cannot speak for your customers nor might my experience be necessarily the same as yours. I’m trying to put things into perspective how I would approach this.
One of the key things I read out of your comments is that you want to do proper risk mitigation and make sure whenever upgrades happen things are still working as intended and you and your team are comfortable putting things into production. I have always been trying to apply the same principles. Now let’s have a look at a .NET upgrade. In the past, some of those upgrades have been large and required also to update third-party dependencies. That comes with a combined risk of being exposed to problems that might come with existing assumptions in the code base that clash with new assumptions or breaking changes in the runtime and, moreover, the risk of third-party dependency updates bringing in another set of changes (or even bugs) that clash with existing assumptions.
Generally speaking, if I can update to a newer .NET version without having to update my dependencies too, is a great thing from a risk mitigation perspective. I would not allow my desire for a feature to interfere with that and increase the risk of failure. Ultimately, like you said, the organization is not willing to make these exercise all the time and the more I succeed, the more likely I’m able to convince my stakeholders that my team and I can be trusted with those upgrades.
An additional aspect I would take into my thought process is whether I want to make the process of upgrading X dependent on a perceived feature set of upgrading Y. Because when I introduce such a dependency, I’m exposing myself to potential delays and stress when Y is not delivered in time. By doing so I have coupled two unrelated things to each other by the mere desire of bundling things together because I assume validating a larger thing once is more effective than validating multiple times smaller upgrades.
So to turn this around, I would say the important question is not whether NServiceBus v8 contains a potential feature that I might like. The question is more: Is there anything in the current version of NServiceBus that would hold me back from upgrading my current .NET Version to the the new version? The answer to that question is: No there isn’t.
Regards,
Daniel