I don't think that is that different from a move to Linux. Certainly, if you do a Linux kernel upgrade, you will want to recertify. And Linux kernels may not have longer shelf live, either:
- Redhat supports their releases for 10+3 years. That is in the same league as XP.
- Ubuntu's long term support is 5 years.
Also, I think part of the problem is that astronauts will bring their own laptops. It may be hard to enforce them to run these long term support kernels (yes, that sounds stupid for an office building where access is that controlled, but space organizations have to take the psychological health of their personnel into account, too)
> if you do a Linux kernel upgrade, you will want to recertify.
The difference is that, if you automate the certification process, you can run it against the bleeding edge branches all the time well before the packages are incorporated into the official release. Any sign of trouble will happen months, if not years, before it's time to upgrade.
You can have a cozy enough relationship with Microsoft, but I doubt they'll let you put their sources on your Jenkins (or BuildBot) servers so that you can run your certification tests continuously. To say nothing about making the Windows build process CI-friendly. That in itself is an undertaking bound to take longer than the shelf life of any operating system.
- https://www.kernel.org/category/releases.html lists 2.6.32 as the oldest kernel with long term support. It was released in December 2009, not yet 4 years ago.
- Redhat supports their releases for 10+3 years. That is in the same league as XP.
- Ubuntu's long term support is 5 years.
Also, I think part of the problem is that astronauts will bring their own laptops. It may be hard to enforce them to run these long term support kernels (yes, that sounds stupid for an office building where access is that controlled, but space organizations have to take the psychological health of their personnel into account, too)