What would be needed for a new release version?

[3geek14]

Reading #3500, sharwell says that there wasn't time to do an audit and a stabilization period for C# 8 before the release of C# 9. And, now that C# versions are released on a yearly cadence, there is unlikely to be time to do those for any new versions.

I'm curious what's involved in an audit and how long stabilizations have taken in the past. Is this something where, with more contributors, a new release would be more likely? If someone were motivated to help this happen, (roughly) how many developer hours would they need to devote to this project?

[sharwell]

The audit involves reviewing each new language feature against each style rule to determine exactly how that language feature should behave in that context. New tests are developed for each relevant case.

The stabilization period is two months without any unresolved issue following completion of the audit and implementation of its results.

[fuzzybair]

I completely respect the need to have a stabilization period but given we are now up to 1.2.0-beta.556 it semes there will never be another release. Given company and customer requirements that we can not have any references to pre-released packages may i suggest that a line is drawn that only features of of the LTS version of .NET are address a.k.a C# 12 and any changes needed for C# 13/.NET 9+ are left until after a release can be made. I really like StyleCop but given it is restricting us to C# 7.3 I am starting to get pressure from the team to find an alternative solution. Convincing the company to allow "un-released" software on this system was denied. I question the road map that is attempting to add support for new features for a new version if the previous version has not yet achieved a "releasable" state.

[fuzzybair]

I just found this comment from @sharwell #3647 (comment) I will try that approach.

[sharwell]

@fuzzybair Keep in mind that the -beta suffix only means "the release has not completed the process described above". Some projects appear to (mis)interpret the lack of a -beta suffix as a statement on the stability of the product in use. The only statements this project makes on stability for any release (with or without the -beta suffix) are the statements in our license:

StyleCopAnalyzers/LICENSE

Lines 15 to 21 in ff5c432

	THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
	IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
	FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
	AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
	LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
	OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
	SOFTWARE.

[kmcclellan]

I've read this and the linked #3647 and am still confused. The current meaning of "beta" employed here seems pretty arcane. The language used by NuGet tools is that 1.1.118 is the "latest stable" package. If that's true, I consider this library no longer maintained. If it's false, then the versioning strategy needs revisited.

I'm stuck with a legacy app that references StyleCop 1.1.118. Rather than update to beta to support C# 8+, I think I will just remove it.

[maettu-this]

I agree with @kmcclellan and would prefer getting a non-beta release soon. I am mainly interested in getting rid of the annoying NullReferenceExceptions (#3136, #3138, #3882, #3916).

[fuzzybair]

@sharwell Fist I really appreciate all the work and support you provide for the community. The only feed back I would give, and what seems to be the general community request, is that The stabilization period is two months without any unresolved issue following completion of the audit and implementation of its results. does not make sense in a modern dotnet ecosystem.

With NetFramework having multiple years between releases, two months is a reasonable window. With dotnet you have the choice of LTS with a three year cycle or STS with an 18 month cycle https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core#release-types. If your stabilization was based on LTS, at this time is .NET 8 and C# 12 https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-versioning then I think two months could still work. However based on commit history

you seem to already be targeting versions of C# that are in .NET 9. With .NET 7 there were large feature changes expected every three months, I have not watched .NET 9 closely but I expect it is the same. Expecting no development or changes for two months with new features every three months does not seem reasonable. My recommendation would to be ether only audit and work with LTS, or reduce the time window for stabilization. One possible approach is that the StyleCopAnalyzers.Unstable is used for STS and the StyleCopAnalyzers package only pulls features for the LTS.