If 12 years is too short, how long timescale do you need?

Python 2's EOL was first announced in 2008.

To be honest, never.

I work on a C program that's about 30 years old. We've slowly moved, at our own pace, to C99, then added some C++ here and there.

I don't ever want to have a forceful change, where I have to go and edit code which has worked correctly for over 15 years, just to make a compiler happy.

GCC deprecates and removes support for target architectures and various other flags with each major release. If you care about receiving security updates for your application, you have to upgrade the compiler, and to upgrade the compiler you may have to make changes to your application and/or physical hardware. Very few of the architectures that were available 30 years ago are still supported by any maintained compiler today.

Similarly, developers are not forced to upgrade to python 3 any more than they are forced to upgrade to GCC 4, in that they can keep using their old tools but they're SOL on maintenance if they don't meet the requirements of the new versions.

So, either your team chose really well 30 years ago, is actively working on an horribly insecure application, or has invested some modicum of effort periodically over the last 30 years to maintain support with the compiler (unlike the developers complaining about Python 3's upgrade window).

We are moving CPUs, we aren't still using amigas and 386s :) but old C code, broadly speaking, still compiles in gcc 8.

Python 2 code, broadly speaking, still runs in Python 3. It's the not-broad parts that are the problem...

Yeah, sorry buddy, but that's just not how modern software dev works. Platforms change, code gets outdated, and whilst older platforms "work", they're likely not taking advantage of all the features that have been added to platforms since that time.

It's much easier/better when you are forced into dealing with the change. At least people can laugh at how annoyed others get when they cry "but you broke everything!".

It's called progress. Get with the times or get outdated.

You say that, but if I boot a Linux kernel, load X, open a terminal and run bash/vim/general terminal tools, almost everything I'm running is probably using a combination of C89/C99/C++98/C++03, all of which are still well support by GCC and clang.

For the first 8-10 Years, migration was not possible for most people for several reasons, shrinking the timescale to 2-3 years for the majority.

Though you could have done most of the work ahead of time.

Python 2 was nowhere near ready for EOL in 2008; making it not very credible.

TBF, Perl 5 is not a language with a stated EOL. "Perl 6" is no longer even considered a successor, and if reason prevails, the language-formerly-known-as-Perl=6 will get a fresh name and cut loose, releasing the "one true Perl" from under its shadow.

> I want to be able to run my software in 10 years

You can! Just buy 10 year old hardware, and run a 10 year old operating system. That's how banks, schools, governments, etc are running 40 year old software.