According to https://support.microsoft.com/en-us/lifecycle/search?alpha=1803https://support.microsoft.com/en-us/lifecycle/search?alpha=1803 is not longer supported since 18 months has passed becuase it's part of the Semi-Annual Channel. The only supported version is Windows 10, version 1803 (Enterprise, Education, IoT Enterprise) now if we support that version or not I'm not sure we have discussed this in !1533 (merged)
Now if we remove support for 1803 we might break support for Windows 10, version 1803 (Enterprise, Education, IoT Enterprise) (needs to be validated)
Proposal
Remove 1803 tests
Remove 1803 from supported version
Remove 1803 helper images builds
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
The only thing I'm not sure about if we remove windows 1803 support if we end up breaking Windows 10 1803 support since we depend on the information that docker info sends and do a simple string match We should probably try out and test this.
@steveazz I agree - let's test. Side note - It feels like we need a read me or page in our docs that calls out which MS OS versions we support. Also per this page, Windows Server 1809 mainstream support end date is May 12, 2020. I can't recall if we talked about our own lifecycle approach for how we want to manage our support for Windows Server OS versions
@steveazz great point - I missed the fact that the builds are the same. We should probably work on !1533 (merged) in the next release. I think @erushton also mentioned to me something about needing to define a lifecycle policy.
I think we will need to revisit our Windows Operation System Support policy for GitLab Runner. It appears to be way too "latest only" oriented for reasonable support of .NET Framework (and building on Windows in general and probably many .NET Core codebases as well). It is also defined to move too fast for real world codebases - especially for software companies who sell their software to customers who need older versions.
I believe most .NET Framework activity will be on self-hosted runners due to
the sheer install volume of...
version pegged build dependencies for any given .NET Framework code base. (which in blended language apps may not be .NET or Microsoft technology)
and even if customers are on a Windows version supported on .com, those that require sizable dynamically installed build dependencies will likely find that per-job build spin up time is way too high and will need a custom machine image to do their build - which would encourage self-hosting runners.
If the .com supported Windows versions policy moves as fast as outlined in the policy, it does not match up with how development teams (esp. non-cloud) generally adopt new OS versions...
but most especially when those teams have customers they distribute their software to who will be on older OS variants long after Microsoft EOL.
If true, the above issues would mean the vast majority of .NET builds will happen on self-hosted runners.
By extension, this indicates the runner binaries need to support the versions customers will want to use when self-hosting runners and not be overly dispositioned to what we will support on GitLab.com SaaS.
Key Issue: I feel we can and should limit the number of Windows versions hosted on .com, but this should not directly translate to what versions of Windows need to be supported by the runner binaries - but especially if the vast majority of usage for .NET can be expected to be on self-hosted runners.
After a Windows version no longer receives mainstream support from Microsoft, we officially deprecate the version and remove it in the next major change. For example, in 12.x we started supporting Windows 1803 because it came out on 2018-04-30. Mainstream support ended on 2019-11-12, so we deprecated Windows 1803 in 12.x and it will be removed in GitLab 13.0.
And it appears we currently develop in accordance with the statement (which makes sense - I'm just noting that the policy is not simply a defensive formal statement while in the background we test and debug for a broader set of OS variants): #6553 (closed)
Supporting real world "In Use" dependency permutations is always hard - even harder at the OS level - but I think if we are going to properly support .NET it needs to be a weighty consideration.
@DarwinJS strict version checks like this one is removing is for Docker Windows executor. I think using Docker executor for old .NET platforms aren't really comparable is that correct?
Users can still run the shell Runner on old Windows machine we just don't provide the same guarantee as to the ones official support by Microsoft. I don't see how we can support an OS that is not even supported by Microsoft. Also if we are talking about .NET Framework can't they still install old versions on the new Windows OSes?
@steveazz - I didn't perceive that this is only for docker executor - so that would make sense for docker only.
My original message is indicating that we should have a strong orientation to lean to supporting whatever maximizes market reach and especially not to default to vendors EOLs which generally hit while a bulk of customers are still on the platform. The runner is very special in that whatever it can't run on, we can't provide build services for.
I'm not sure about the forward reach of SDKs - but even if it were unlimited (pretty sure it's not) - this leaves out the detail that there can be MANY third party build dependencies that do have limited forward compatibility.
But even more than that, many developers - whether developing on Windows or not - want to build and especially test on exactly the target platforms they say they support on their "box". Runners have to support both "in-house" and commercial software development - I think the commercial ones would be even more concerned about this.
Again, not making a case to keep all kinds of old junk supported (as you see in my response to Daniels question about go support) - but that a default orientation to vendor EOL for Windows does not seem to serve our customers and our prospects for maximizing the market reach - for all platforms really.