comment on

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.

For 5.8.x, binary compatibility was maintained across 9 releases & 5+ years;
For 5.10.x: binary compatibility was lost after just 2 releases & 1.5 years;
For 5.12.x: binary compatibility was lost after just 4 releases & <1 year.
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.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

In reply to Re^5: How to install Tk-ImageButton module in perl 5.12 using ppm by BrowserUk
in thread How to install Tk-ImageButton module in perl 5.12 using ppm by vichu001

Are you posting in the right place? Check out Where do I post X? to know for sure.
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
Want more info? How to link or How to display code and escape characters are good places to start.


Perl-Sensitive Sunglasses
	PerlMonks