In my last journal entry, I was faced with the problem of figuring out why a dependency on 5.8.x was there. In the example of a 5.6.1 fix to Catalyst that jk2addict posted, it highlights the fact that core module changes in the main only get made to the core distribution and nothing else. In the case of Class::Struct, and from what I found File::Path too, nothing is 5.8.x specific, and there is no reason why they wouldn't work with 5.6.1.
Unfortunately some of us are stuck with working on 5.6.1 for a variety of reasons. This now means that we are largely stuck with working with broken and old versions of modules that we have no real reason to. We could hack a distribution together for the upgraded modules and make our own SDK, but that dilutes the process to my mind. If there are fixes to a core module, then there should be a simple way to get access to them from CPAN. There are other modules that have their own life outside of the core (e.g. ExtUtils::MakeMaker), so why not these?
It's become increasingly frustrating to find more and more distributions dependent on 5.8.x. The Perl community, at least those fairly vocal with in it, are just the tip of the iceberg of users. I can understand people not wanting to cpan-test on 5.6.1 (or earlier), but there is a large number of users out there who now have no idea whether a CPAN distribution works on their system, unless they try it themselves, as all the cpan-testers run varieties of 5.8.x. Otherwise there would be a distinct increase in the number of NA reports being produced, and would hopefully prompt authors to look at whether their modules work on earlier versions (hint: Perl::MinimumVersion). I have no idea what kind of distribution there is for the perl interpreter versions out in the wild, but I expect there is a significant number running 5.6.1 and probably earlier too.
At the Perl 5 Day in August, there was some discussion surrounding the SDK idea. I would be happy with that, providing there was a version independent release, which could run on any version of the interpreter, or an SDK of the core modules that work with a specific version. This would likely mean a lot of work for the maintainers to ensure that a module only went into the SDKs for which is applicable, but I think that could be automated once they got the hang of it. It would make life easier for those of not able to upgrade to the latest and greatest version of the interpreter every few months. Perhaps once CPAN::YACSmoke is stable and there isn't much more to develop on it, I can look at some automated SDK build process, but for now I guess I'll have to wait for others to have the tuits to work on the idea.
This would likely mean a lot of work for the maintainers to ensure that a module only went into the SDKs for which is applicable, but I think that could be automated once they got the hang of it
As you say, this is a lot of work.
I heard companies complaining about how not having this cost them a lot of money. But I don't see any of them lifting a finger to try to help solve it. If this truely is their itch, why are they not helping scratch it?
(Yes, I am angry about companies that are effectively all take and no give. Their problems are genuine. But their intended solution seems to be moan, and hope that someone else volunteers to do their work for them. Given that they are commerical organisations, and the solution they seem to assign to this problem is "volunteer can fix this for us", their actions send strong signals that the cost of this problem to them is really sweet fanny adams, rather than way big. Where's their JFDI?)
Re:it's the tuits...
nicholas on 2005-10-10T19:57:08
Translating this to positive action points - if anyone reading this does want it, but doesn't have (free) time, can you make a business case to your employer to work on sorting out the problem as part of your job?
Re:it's the tuits...
barbie on 2005-10-11T08:50:01
I think perhaps the problem isn't as obvious to commercial organisations. Their developers learn how to make the fixes themselves rather than have a standard install they can upgrade. They don't escalate the problem.
It's been a problem for me, as I want to do reliable cpan-testing, and unfortunately there are a growing number of distributions relying on specific versions of core modules.
I do think this would be a nice task for someone new to an organisation, where by they can learn about core modules, dependencies and CPAN. It would give them good exposure some very relevant skills. Perhaps even a project on the Google's Summer of Code list for 2006
;)
