Re^3: How to install Tk-ImageButton module in perl 5.12 using ppm

[BrowserUk]

No not really. In fact, not at all.

Half way through having skipped over the retelling of all the tired old pumpking jokes. and we get to the point were he is lauding the fact that they can put out new releases at whim. Which IMO is the problem not a solution.

Monthly releases may be great for developers -- though with decentralised version control and nightly builds it seems unnecessary -- but frequent, dump-everything-you-have-and-start-again releases are a nightmare for users. Especially when the "What's new?" list associated with the major point releases is so light.

[anneli]

retelling of all the tired old pumpking jokes

I'm new here, so I didn't know they were old :D But doubly, I was following the Japanese (which just said "pumpkin"), and assumed the English was a typo/mistrans.

they can put out new releases at whim. Which IMO is the problem not a solution.

It may not be a solution, but it's certainly never a problem in itself. If your issue with that is because it allows the developers to release too haphazardly for your liking, then it's an issue with the developers and their release process, not the build process.

frequent, dump-everything-you-have-and-start-again releases are a nightmare for users

Of course; but I don't think it's quite gotten to that.

[BrowserUk]

frequent, dump-everything-you-have-and-start-again releases are a nightmare for users

Of course; but I don't think it's quite gotten to that.

I guess we'll have to agree to differ on that.

The evidence I have to support my opinion is the irrefutable release history.

1. For 5.8.x, binary compatibility was maintained across 9 releases & 5+ years;
2. For 5.10.x: binary compatibility was lost after just 2 releases & 1.5 years;
3. For 5.12.x: binary compatibility was lost after just 4 releases & <1 year.
4. For 5.14.x: ?

To further make the case, go back and look at all the new features that come on board during the 5.8.x era; and the further developments and substantial gains from the compatibility breaking 5.10.0 release. Then look at how little more has come as a result of 5.12 & 5.14. Now, I'm very sure that the developers would argue that the internal changes that brought about those two binary compatibility breaking releases are required for lots of good stuff to come going forward, but so far, I see little sign of that.

5.10.0 brought many features that we had to wait a long time for -- perhaps too long. The increased release rate shortens the time between the development of the idea and it getting into the users hands, but it also has downsides. A balance needs to be struck.

It is my assertion that through the 5.10 -> 5.12 -> 5.14 transitions, that balance went too far the other way. That the internal changes that brought about the need to have two major point releases in a single 2 year period could have been combined into a single major point release by keeping them in the development branch, whilst still applying bug fixes as minor point releases to 5.10.

The Perl development process makes great play -- I would say too much so -- of backward compatibility at the source code level. But it is my assessment that far more people are badly affected by the breaking of binary compatibility than will ever be so by the removal of long deprecated obscure corners of syntax, or long-standing bug-become-feature fixes.

But the core developers are, by their nature, going to have compilers installed and build their working systems from source. As such they do not see the affect on the users of the breaking of binary compatibility, so give it less consideration.

There is an old development principle that goes: "use what you sell". Of course, Perl isn't sold, and the idea that its developers will ever use binary distributions, forlorn, but the reasoning is sound.