On 10/31/06, Jonathan Rockway <[EMAIL PROTECTED]> wrote:
On Monday 30 October 2006 18:16, David Golden wrote: > Bundle gives the option of either freezing a particular version (by > specifying a distribution file) or else fully upgrading to the > absolute latest version (by specifying a module).
Oh, I did not know you can freeze versions using a Bundle. I could have guessed I am not going to be the first one to come up with such idea :-) For my purposes the fact that new versions of modules come out on a daily basis is not a problem. It is THE problem. My guess is that most people (especially companies) will prefer "stable" or "cross tested" over "new". A lag of several months or a year in any of the modules is not necessarily a bad thing for them.
The problem I've experienced with this method is that authors tend to delete their modules from the CPAN (at the strong urging of messages on the PAUSE website). This leads to broken bundles (or ports in my case), which is mildly irritating. However, adding logic to get the files from the backpan would eliminate this problem. (But then there's the bandwidth issue -- do we really want automatic tools hitting the backpan?)
What about adding a mechanism to PAUSE to map module/version pairs to the bundles they are mentioned in? One could parse the most recent bundles, extract the list of modules and the frozen version number. When the module author is about to delete old versions the form could show her a list of bundles that are still pointing to a particular version. I am not sure if preventing the deletition would be a good idea but warning the author might be.
The other issue is of security updates. I would hate to lock people into insecure versions of modules. Maybe there needs to be (another :) flag that says "don't distribute this version anymore, use x.y.(z+1) instead". Problems like this might be too late for the 5pan to solve, though. (I'm not sure I like any of the 6pan proposals, though, so fixing the current CPAN is not necessarily a bad idea or a waste of time.)
With the above module/version to Bundle mapping the author could find the bundles using the insecure version of the module and urge them to update the bundle. In any case she would be able to remove that version from CPAN. If the new secure version of the module is breaking some other CPAN modules then I am not sure a forced upgrade would be a good idea at all. On the other hand if there is a newer version with the security fix and the module works well with the rest of the CPAN modules then Bundle authors could update their bundle in a reasonable time. Gabor -- Gabor Szabo http://www.szabgab.com/
