Why is 4.7.50 marked with "Dev status: Alpha"?

Feb 5 at 5:15 AM
Is it really alpha? Or should this in fact be "Dev status: Stable"?
Coordinator
Feb 5 at 12:21 PM
I consider it alpha. It's the first official build I've done for StyleCop, it includes some pull requests I merged in from others (but haven't yet thoroughly tested), and supports VS2015 but does not support any C# 6 syntax (analysis errors out in any files that have C# 6 syntax).

I was planning to add support for C# 6 syntax, then create a beta release. After some additional testing, I'll create a stable release.
Feb 5 at 12:24 PM
OK, thanks.

Can you explain how the version numbers will work? I assume you are not using SemVer (perhaps codeplex doesn't support it) so will the new version also be 4.7.50 but marked "stable" separately?

I've already released StyleCop.MSBuild 4.7.50 based on the current 4.7.50 binaries but I can always release 4.7.50.1 if and when a stable is released.
Coordinator
Feb 5 at 12:41 PM
While catching up (merging pull requests, updating VS and R# support, etc.) I was planning to continue using the existing versioning scheme, which was to use 4.7.X and just increment X.

I thought about using 4.8, but it looked like AssemblyVersion is assumed to be 4.7.1000.0 until major version 5, and I thought it'd be odd to have AssemblyVersion of 4.7.1000 and AssemblyFileVersion of 4.8.X.

So tentatively:
4.7.49 - The existing stable release
4.7.50 - Alpha release (includes VS2015, R# 8.2.3, and various pull requests)
4.7.51 - Beta release (includes C# 6). Will be changed to Stable if no issues are found.
5.x - Start following SemVer, upgrade everything to .NET 4.0+, and probably drop support for any no-longer-supported versions of VS and R#.
Feb 5 at 5:59 PM
csdahlberg wrote:
I thought about using 4.8, but it looked like AssemblyVersion is assumed to be 4.7.1000.0 until major version 5, and I thought it'd be odd to have AssemblyVersion of 4.7.1000 and AssemblyFileVersion of 4.8.X.
I write code that has a fixed AssemblyVersion and a constantly increasing AssemblyFileVersion. The way this works is that the AssemblyVersion is constant until a non-compatible change is made to a public interface (we avoid these like the plague once the initial customer release is shipped). This satisfies .NET as new versions keep working in old apps. Increasing the AssemblyFileVersion keeps Windows Installer happy as it ensures that the new file replaces the old file during an upgrade.
Feb 6 at 2:15 AM
AssemblyVersion is assumed to be 4.7.1000.0 until major version 5
What is making this assumption? Will something break if AssemblyVersion becomes 4.8.0.0?

I'm unfamiliar with codeplex, but is it possible to bake the pre-release identifier into the version? E.g.

4.8.0-alpha01
4.8.0-beta01
4.8.0
Coordinator
Feb 6 at 12:39 PM
What is making this assumption? Will something break if AssemblyVersion becomes 4.8.0.0?
Other libraries or applications that reference StyleCop (such as custom analysis rules) could break.
I'm unfamiliar with codeplex, but is it possible to bake the pre-release identifier into the version?
I just added "(Alpha)" to the release title here on CodePlex, but neither MSIs nor .NET assemblies can include anything but a 4-part numeric version.
Feb 7 at 12:12 AM
Other libraries or applications that reference StyleCop (such as custom analysis rules) could break.
This is a solved problem. NuGet adds appropriate binding redirects during package installation. The ecosystem is already built this way. I don't see any reason for freezing the assembly version unless there is something highly specialised going on.
neither MSIs nor .NET assemblies can include anything but a 4-part numeric version
That is true, but the published package filename does not need to conform to the MSI/assembly version. E.g. if you look at typical NuGet packages, the assembly version is 1.2.3.0 but the package version may be 1.2.3-beta01. This is usually also reflected in the AssemblyInformationalVersion attribute which has no restrictions on content. Similarly for MSI's, the file may be called MyApp.1.2.3-beta01.msi with the assembly versions being 1.2.3.0, again with the option to have the AssemblyInformationalVersion as 1.2.3-beta01.
Feb 7 at 12:17 AM
BTW - some NuGet packages do choose to freeze the AssemblyVersion to lessen the binding redirect burden, but the package version still get incremented independently. E.g. JSON.NET freezes it's AssemblyVersion on majors, so 5.0.0, 6.0.0, 7.0.0, etc. but the package version is bumped according to SemVer on each release, so packages 7.0.0, 7.1.0, 7.1.1, 7.2.0, etc. will all have an AssemblyVersion of 7.0.0.

In the case of StyleCop, there is already a mismatch. The package version is 4.7.50 but the AssemblyVersion is 4.7.1000.0. If you want to keep AssemblyVersion frozen to lessen binding redirect burden then, whilst it is a shame that the AssemblyVersion isn't frozen at 4.7.0.0 or even 4.0.0.0, I don't think it is a great crime to leave it at 4.7.1000.0 whilst the package number increments to 4.8.0.
Coordinator
Feb 7 at 3:36 AM
Other libraries or applications that reference StyleCop (such as custom analysis rules) could break.
This is a solved problem. NuGet adds appropriate binding redirects during package installation. The ecosystem is already built this way. I don't see any reason for freezing the assembly version unless there is something highly specialised going on.
The NuGet ecosystem is built that way (and it certainly is a solved problem there), but the NuGet ecosystem is also built on SemVer, which StyleCop has not thus far followed. It's been a practically abandoned project for 2 years, and neglected for a while before that, so it shouldn't be surprising that it doesn't follow current common/best practices.
neither MSIs nor .NET assemblies can include anything but a 4-part numeric version
That is true, but the published package filename does not need to conform to the MSI/assembly version. E.g. if you look at typical NuGet packages, the assembly version is 1.2.3.0 but the package version may be 1.2.3-beta01. This is usually also reflected in the AssemblyInformationalVersion attribute which has no restrictions on content. Similarly for MSI's, the file may be called MyApp.1.2.3-beta01.msi with the assembly versions being 1.2.3.0, again with the option to have the AssemblyInformationalVersion as 1.2.3-beta01.
StyleCop is currently distributed via an MSI file, not via NuGet, and I don't think it's appropriate to try to force it to follow best practices for versioning NuGet packages. With NuGet packages, you can have 1.2.3-beta01 and 1.2.3 and they will be seen as different versions within the NuGet ecosystem. With MSIs and DLLs, they will all just have the same version of 1.2.3, which can easily cause problems (especially with MSIs). Those problems would not be solved by adding "-beta01" to the filename.
In the case of StyleCop, there is already a mismatch. The package version is 4.7.50 but the AssemblyVersion is 4.7.1000.0. If you want to keep AssemblyVersion frozen to lessen binding redirect burden then, whilst it is a shame that the AssemblyVersion isn't frozen at 4.7.0.0 or even 4.0.0.0, I don't think it is a great crime to leave it at 4.7.1000.0 whilst the package number increments to 4.8.0.
There is a mismatch of the revision, but the major and minor version components currently match. Changing to 4.8.0 would cause the minor version to also no longer match.

I wanted to make this initial "catch-up" phase as painless as possible for existing users, build processes, custom rules, etc. Since I didn't see a strong reason to use 4.8, I opted to continue to just increment the revision as has been done for many similar preceding releases.