chromatic wrote:
On Tuesday 04 April 2006 10:32, Tels wrote:


There is also the point that supporting ancient Perls means you
can't use all the new, wonderfull features that were added to later
versions of Perl, like our, warnings etc.


This to me is the biggest problem. After 6 years, is it finally okay for me to use such exotic features as lexical warnings and lexical filehandles, just to satisfy someone who refuses to upgrade an eight year old installation of Perl?

The answer is "it depends".

I'll have a more definative answer once we get the dependency graph stuff sorted out.

But as a stopgap answer, I offer the following.

Yes you can, as long as nobody else uses your module.

If you write something for 5.8.4, and then over time dozens of other modules that use yours are all 5.005, then it might be worth looking at doing some back-porting, because you've become the weakest link.

That said, to some degree they made that situation themself.

On the other hand, if YOU were adding a module as a new dependency of something you already have that needs 5.005, and 100 other 5.005 things already use, then you just broke 5.005 support on them all.

So I'd say on CPAN 5.005 is it's something you expect others to use, 5.6 for general things if you want, 5.8.4 is you need unicode (or whatever other special cases apply) and if people start using you and you are getting in the way, consider dropping.

And once we get CPAN and CPANTs graph modules set up, I have an algorithm in mind that should be able to give us a list of the Backcompatibility Weakest Links, the modules that are prevent other modules below them from working on the versions they say they can.

Are there such people who absolutely want to use the latest code I wrote without actually upgrading their systems?

I'm trying to figure out why I've been sending patches to p5p for about five years now if people complain when I take advantage of the bugs they fix. At some point, it would be nice if people were to use software released this millennium.

Ever written software for government?

It's routine to be required to offer a 10 year support period.

This comes up more often that you might think.

And so as my gold standard for back-compatability, I use 10 years. A decade is a nice round number.

If it's something that isn't very core'y, I use a secondary support period of 5 years.

Seeing as the worst support cases are about 10 years in a variety of countries and situations, I think that is what we should be aiming for for highly used CPAN modules.

Which last time I checked is now 5.005.something

So I aim there.

Adam K

Reply via email to