Best practice for R# 9+ extension package IDs

Now, that we cannot service more than one R#/wave version in one package anymore, what is the best practice to handle the different wave-versions in extension packages?

controlflow used postfixes in the package Id:

https://resharper-plugins.jetbrains.com/packages/ReSharper.Postfix.R90/
https://resharper-plugins.jetbrains.com/packages/ReSharper.HeapView.R90/

... others just created a new package Id, like
https://resharper-plugins.jetbrains.com/packages/AngularJS/ (for R# < 9)
vs.
https://resharper-plugins.jetbrains.com/packages/JetBrains.AngularJS/ (for R# 9)

... and then just use use a new package version to support the next wave version? What about (bugfix) updates for older waves?

4 comments
Comment actions Permalink

The main reason for changing the IDs was that the installer required a "." in the package ID name, and any package with a single segment, e.g. AngularJS, wouldn't install. However, versioning caused more of an issue that expected, and forces our hand when trying to keep support for 8.2 while people upgrade.

We're using a feature of the NuGet gallery called curated feeds to put uploaded packages into a separate feed based on what packages they depend on (ReSharper 8.x would go into the ReSharper_v8x feeds, Wave 1.0 goes into the Wave_v01 feed). Unfortunately, the curated feed will always give the latest version of the package, even if it no longer fits the requirements of the feed. So, currently, uploading a new version of an existing package that changes the requirements will block the install for a previous version in its supported host - a ReSharper 9 compatible package will block installation of the ReSharper 8 version of the same package. This is purely a server side issue, and I'd love to address this, but it's just how the NuGet gallery works, and may not be an easy fix.

As for what happens when 9.1 comes out, we're expecting packages to just support the latest version (with pre-release packages to support EAP builds that don't block the previous RTM version). Several reasons for this - licensing is now completely based on subscriptions, so it should be easier for customers to stay up to date with the latest version of ReSharper - e.g. we're less likely to have people stuck on 9.0 when 9.1 or even 10.0 comes out. But more importantly, very few package authors took advantage of the ability to support multiple versions in a single package. And so, this scenario was dropped when redesigning the way packages worked for the new installer and shared binary architecture. So, no bug fixes for older versions (we weren't expecting the curated feeds issue, and had anticipated that bug fixes could be handled by uploading support for a new version as a new major version number, and bug fixes for the older version could be a new minor or build number for the previous version).

The tricky part is the overlap when a new version of the platform is released. Customers on the new version would get your new package version (or have to wait until it was available). Customers with the extension already installed in an older version will be fine - the extension manager won't update to the latest version because it's not compatible. But customers on an older version that don't have the extension won't be able to install it. Adding ANOTHER package version (Foo.Bar.R91, Foo.Bar.R92) would work around this, but it's not nice. Fixing the gallery would be a much nicer solution...

0
Comment actions Permalink

Hi Matt,

many, many thanks for your answer.

As for what happens when 9.1 comes out, we're expecting packages to just support the latest version
[...]
The tricky part is the overlap when a new version of the platform is released. Customers on the new version would get your new package version (or have to wait until it was available). Customers with the extension already installed in an older version will be fine - the extension manager won't update to the latest version because it's not compatible. But customers on an older version that don't have the extension won't be able to install it.


For me that's not a solution because there will always be users, which can't upgrade to the latest R# version near the time R# and it's extensions will be updated. There are a many reasons for this like a slow IT-service desk, fear of bugs in a x.0 version, waiting for a specific R# extension with a lazy developer, incompatible settings/live templates, which have to be migrated first, an expired subscription, ...

What about a user, which wants to keep, e.g. 8.2 when 9.0 is released and has to reinstall ReSharper or the whole machine. He won't be able to reinstall all the extension packages he used in 8.2? An example for this is Caliburn.Light.Annotations, which can't be installed in R# 8.2 at the moment.

Adding ANOTHER package version (Foo.Bar.R91, Foo.Bar.R92) would work around this, but it's not nice.


What are the disadvantages of this approach?

0
Comment actions Permalink

Yeah, this is where a fix to the gallery to only return compatible packages from the curated feed would sort everything. I want to check that out before the 9.1 EAP really gets started, or at least too far along.

I can't really think of a massive disadvantage to having multiple packages, other than it's an ugly solution. Personally, I don't want to have to maintain multiple packages - I'd rather just have a single package that I have to maintain, rather than create a new one for each platform version. And I'd rather not see "Blah blah for ReSharper 9.0", "Blah blah for ReSharper 9.1", etc. in the gallery. It's a fudge. I'd much rather see the gallery support this properly.

0
Comment actions Permalink

All right. Thanks for your answers!

0

Please sign in to leave a comment.