[run4yourlives2]

Serious Answer: Because some of us have some rather large perfectly working systems written in 2.7 and using lots of different libraries that moving to 3 is a major project requiring a good amount of time and effort.

Not all of us have hobby-sized projects on the go.

[dbcurtis]

OK, but this has been a very long transition. There has been lots of time to evolve to 3.x. Has the primary barrier been the slow transition of library dependancies?

I'd really like to understand this from a technology transition management standpoint.

If you'll allow a strained analogy, the 2.7 to 3.x transition appears in retrospect like an exercise in herding cats, because the transition was done using cat-herding style incentives. What should have been done differently to make the transition into greyhounds chasing a rabbit? What should the rabbit have been?

Any technology that lives long enough eventually has to transition its customer base. I'm trying to learn to identify rabbits.

[run4yourlives2]

It's been a long transition, yes. So long, that 4-5 years ago, developing a new application in 3.X was a non starter. Hence, 2.7.

Now, you have 2.7 apps that are very mature, stable and reliant on lots of little things. Okay, big job.

Now let's throw another wrinkle into this. You can pay good money to develop your next feature, or to port your system to 3.x. One adds real value to your customers and improves your bottom line. One lets you say you are on 3.x and gets nods of approval from random programmers.

What do you think a business is going to do? Exactly.

When will we eventually port? Sometime shortly after 3.x becomes the overall standard. THIS is actually what we are seeing right now, which is great, but that hasn't been the case up until the last year or so.

>Any technology that lives long enough eventually has to transition its customer base.

While true, this costs money, time, and effort. So you better be damn well sure there is a good ROI that is something more than "This code that nobody but programmers see is more elegant and properly structured".

There's a reason banks are still using COBOL after all...

[chc]

Asking this question without disqualifying the answer "No breaking changes whatsoever" usually just generates a bunch of different ways of phrasing that.

[dbcurtis]

No, I don't buy that. IBM successfully transitioned a huge customer base from 709/7090 36-bit words to System 360 32 bit words. The transition from 32 to 64 bit addresses was rocky for a lot of architectures. DEC Alpha, Intel Itanium. But are you still running a 32 bit OS?

K&R C no longer compiles. Not that the C to C++14 transition is what I would call an example of greatness, but it is somewhere along the success spectrum.

Seriously, you will someday need to transition your customer base. How do you plan to do it?

[xrange]

>K&R C no longer compiles.

    foo@virt-ubuntu:~/c$ gcc --version
    gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406
    Copyright (C) 2016 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
    foo@virt-ubuntu:~/c$ cat 'k&r.c' 
    #include<stdio.h>
    
    int main(argc, argv)
        int argc;
        char *argv[];
    {
        puts("hello, world!");
        return 0;
    }
    
    foo@virt-ubuntu:~/c$ gcc 'k&r.c' 
    foo@virt-ubuntu:~/c$ ./a.out
    hello, world!

[chc]

Yes, I agree with you. That's why I said you should disqualify that answer. It's by far the most common answer, but it's also obviously not the right answer.

[kzrdude]

Even hobby sized projects can be a major chore. Especially if it's wrapped up in a Gtk transition too.