What's going on with revision number?

Question

I just saw that site revision is 1.0.0.0

rev

Someone just dropped it to default state, or there is integer overflow?

• TheWanderer: Could it be the first version of the new design?
• αλεχολυτ: @TheWanderer which one is new?
• TheWanderer: the whole responsive design that's been such a big deal.
• Nick Craver: We woke up this morning and thought "ya know what? I think we finally nailed it y'all - let's call it 1.0"
• Sonic the Anonymous Hedgehog: @NickCraver Let's not forget about your tweets
• Nick Craver: Those are just nasty rumors
• Sonic the Anonymous Hedgehog: @NickCraver Also, the tag wiki for svn-revision says it's about the revision number at the bottom. If that's not correct, please rename/merge the tag.
• curiousdannii: @Nick Can you finally remove the attribution required link if you're updating that part of the code/templates?
• Nick Craver: @curiousdannii I'm not touching any of that - the issue is miles away from the views.
• user152859: @Sonic what makes you think it's not correct?
• Sonic the Anonymous Hedgehog: @ShadowWizard The tweet right after the one I linked.
• Cody Gray: Why would we remove the "attribution required" link, @curiousdannii?
• curiousdannii: @Cody because it's against the terms of the CC license, and because the staff have already said they're intending to.
• Cody Gray: @curiousdannii What? How is "attribution required" "against the terms of the CC license"? The CC BY-SA license explicitly requires attribution.
• curiousdannii: @Cody See here. It's the contents of the blog post that are the problem. The CC BY-SA license does not let you dictate specific ways in which attribution is to be given.

Answer 1

This is now fixed. It may be silly, but I bet others hit it so...details! TL;DR: a code move in our .NET Core migration read AssemblyVersion from an assembly that was set (via AssemblyInfo.cs during a build) to one that wasn't (an SDK project which doesn't have that stuff).

I figure it's best to just literally paste my commit message here:

When we moved assembly versioning down to StackOverflow.Common, the footer went back to 1.0.0.0. This happened because our build replaces the versioning in AssemblyInfo.cs which doesn't exist anymore in .NET Core. We need to instead replace it as <Version>...</Version> in the .csproj. We may change to git versioning here later, but this maintains the date version for the moment (e.g. in the footer).

This change is paired with a "File content replacer" feature on the TC builds to do the actual replacement. Again: this gets us back to working...but we should replace how all this works with built-in git versioning and a date feed from elsewhere if we want to maintain that in the footer.

This fixes: meta.stackexchange.com/questions/327167/whats-going-on-with-revision-number

Note: locking the build replacement down to StackOverflow.Common.csproj since it replaces the <Version> element which catches this in StackSnippets.csproj:

<PackageReference Include="System.ValueTuple">
 <Version>4.5.0</Version>
</PackageReference>

While this should be:

<PackageReference Include="System.ValueTuple" Version="4.5.0" />

...the tooling does that and the problem will just occur again. So let's just side-step most of the noise of such things by locking it down.

Setup in TeamCity:

Path pattern: "**/StackOverflow.Common.csproj"
File encoding: UTF-8
Search for: (?-m)(<Version>)(.*)(<\/Version>)
Match case: true
Regex: true
Replace with: 1ドル%system.build.start.year%.%system.build.start.month%.%system.build.start.day%.%system.build.number%3ドル