automake: Today I back-ported the versioned install code to the 1.4 branch. The Gnome hackers, particularly hp, convinced me it would help them transition to 1.6 more easily. So, despite my wish for 1.4 to simply die, it lives on... expect the next "final" release soon.

Really this problem comes from some deeper problems with the automake process dating back several years. Basically, I (at the time there weren't other active automake hackers) didn't do a release for 2 years, and when I finally did it was too divergent, had too many new features, and too many bugs. So now, even though 1.6 is really quite good, people are still stuck. This is made worse by the massive changes autoconf has gone through in the meantime.

Lessons continue to be learned here. (Which, incidentally, is unpleasant since it means we are still making mistakes.) We haven't provided smooth upgrade paths from release to release, nor have we even documented the way to upgrade. That hurts the users.

These probably seem like simple things to get right. And they are. Unfortunately for everybody, I still seem to approach automake as though it is the same project it was when I started: a small script, used by a few friends, which I can randomly hack to pieces without consequence. But that world view is really out of sync with reality now. I don't know what excuse the other developers have :-).

As you can see the changes must start on the inside, with the mindset of the developers. Over the years automake has gone through some process upgrades. For instance, we have a documented release process. However, things like this help only in limited ways: when misused they can be an attempt to address an internal problem (my carelessness in making certain changes) via an external method (increased process enforcement). If this works at all, it can only be in limited ways.