Stylecopanalyzers: When will 1.1.0 be released?

[tdworshak]

Hi, What are the plans to release 1.1.0? 1.1.0 Beta 4 has been out for about 6 months now. We are seeing issues with 1.0.2 with C# 7 code (understandable), but are reluctant to upgrade to a Beta release. Thanks!

[pdufrene]

Same comment here, with C#7, we have to exclude more and more rules locally
(With #pragma disable warning...)
This becomes tricky

[sharwell]

For this project, I would encourage upgrading to the Beta release. Beta 5 is due soon, and should bring the project up to support C# 7.2.

[tdworshak]

Ok, thanks for the guidance. We will give the Beta a try. Cheers.

[Lexcess]

Given we're another month on, I'd like to add another voice to the desire to get a release out soon (I do see that we're at beta 6 now).

Just today we've hit another set of issues around how SA1001and SA1008 play with Value Tuples. If you feel the beta is good enough for users to apply to production code should these not just be actual releases?

The current big bang approach is forcing us to disable more rules over time and just seems to hold the risk of way more issues you finally do release. Rather than a quicker cadence with a smaller set of changes (and probably fewer resultant issues).

[warrenrumak]

@sharwell We're another three months on with no progress. A couple more blinks and it will be a full year since the last non-beta release, and you're already at 840 commits since then.

Do you need some help getting 1.1.0 out the door? It doesn't need to be perfect. Things can wait for 1.2.0 or a later version.

[warrenrumak]

@sharwell Pretty rude of you to not reply to this direct question and offer to help. Please do better.
@vweijsters Perhaps you'd like to chime in here as well. Do you guys plan on making tangible progress on the next release or not? A lot of people are waiting.

[vweijsters]

Can't really comment on that, as I leave the release part to @sharwell. But any help is appreciated. Where possible I will review and merge submitted pull requests.

[sharwell]

I get more than 1000 notifications per day, so it's not uncommon to miss one. We should be able to update for the 7.3 release over the next two months before moving to a stabilization period with a target release date of August to October.

Note that for analyzer packages, the pre-release indicator has no real impact, so the "stable" release is cosmetic. It primarily indicates the release has gone through the stabilization period.

[Arithmomaniac]

Note that for analyzer packages, the pre-release indicator has no real impact, so the "stable" release is cosmetic. It primarily indicates the release has gone through the stabilization period.

One impact is that another Nuget package can't reference it unless it is also in pre-release. (My company has a metapackage with some built-in runsettings to enforce code quality.)

[sharwell]

One impact is that another Nuget package can't reference it unless it is also in pre-release.

True, but for the same reasons as indicated above, the metapackage could likely be pre-release indefinitely with no production downside.

[Arithmomaniac]

Another (minor) impact is that in order to keep up with the current tooling, you have to turn off "stable-only" for _all_ of your packages in the VS Nuget Package manager. Then VS prompts you to upgrade all of your packages to the pre-releases.

[Lexcess]

I have the exact same use case as @Arithmomaniac. We issue pre-release metapackages to test other analyzers, rulesets and other changes. Always being pre-release take this option away. Not to mention having VS flagging all your (non-development) packages for an upgrade.

[Lexcess]

Thinking a little more about this. Given we're now saying that the Betas are cosmetic would the answer be to fork the repo, subscribe to all commits and simply publish to Nuget.org every time the fork sees a git tag? It'd be a bit of a hassle but at least it would get around this problem.

That gives you the plausible deniability of their being a stable release, without leaving people who can't consume pre-release packages marooned on an obsolete build.

[sharwell]

Some of the betas have definitely had bugs in them. I'll put some thought into the approach of using a second package and see if that's something that could work.

[sharwell]

The approach I'm thinking of would use two NuGet packages. Had we applied it all along, it would look something like this. The package versions in bold would contain the analyzer assemblies, and the other side would be a metadata-only package that declares a dependency on the package with code.

| StyleCop.Analyzers | StyleCop.Analyzers.Unstable |
| --- | --- |
| 1.0.0-beta017 (metadata only →) | 1.0.0.28 |
| 1.0.0-rc1 (metadata only →) | 1.0.0.29 |
| 1.0.0 | 1.0.0.32 (← metadata only) |
| 1.1.0-beta007 (metadata only →) | 1.1.0.38 |
| 1.1.0-beta008 (metadata only →) | 1.1.0.39 |

Users who need to depend on pre-release versions of StyleCop Analyzers without getting flagged by NuGet as a prerelease would simply declare their dependency on StyleCop.Analyzers.Unstable instead. The StyleCop.Analyzers package would continue to function in the same manner it does today.

[Lexcess]

So I'm definitely in favour of this over the current release model.

That said, I wonder if you're making it harder for yourself. Bugs are going to happen, probably even in the stable releases. If you simply roll out the beta then push the un-tagged version a week or so later, would that be so bad? Worse case scenario you could re-push the old bits in a new package.

Ultimately this is your process and it fixes the problem. So if it works better for you it has my support.

[Freelix]

Any ideas @sharwell if this plan will take place in a near future ?

[DrGriff]

With Visual Studio, they're releasing a new update every few weeks (or so it seems). I see huge benefits with the more frequent release pattern. Please could StyleCop adopt a similar release frequency (release less more often).

[lflender]

I agree on this and I think many people do. We can't wait for a perfect version to release. Last stable release was in May 2017 and most companies will not use the pre-release or unstable versions. Please release an official version!

[sharwell]

Please could StyleCop adopt a similar release frequency (release less more often).

This is the role of the beta and unstable releases. We recently updated the deployment steps to increase our ability to publish packages on a shorter time line.

[Nashuim]

I noticed that you recently released the 1.1.1 beta. Does this mean that we can expect a stable 1.1.0 release soon?

[sharwell]

@Nashuim We were forced to change the number of the 1.1.0 release due to limitations in SemVer 2. See #2815. 1.1.0 and 1.1.1 are the same release.

[Nashuim]

Then is the beta still recommended for C# 7.2+?

[sharwell]

@Nashuim Yes, that's correct. The 1.1 releases were the first to support C# 7 syntax.

[rymeskar]

@sharwell Another months have passed. Any news regarding the stable release of 1.1.

[lflender]

Asking the real question! Almost 2 years since 1.0.2 :(

[perlun]

@sharwell I believe this issue could be closed now. https://github.com/DotNetAnalyzers/StyleCopAnalyzers/releases/tag/1.1.118 was released on Apr 29, 2019.