Typically they're called "requirements" because they establish a minimum. If a particular version is known to work and passes the tests, why require a system to have a higher version installed? Why instruct users to install from apt at all if they're just going to have to update all the modules from CPAN anyway? Why warn them they *need* to upgrade if in reality they don't? Issuing a warning during the build process should indicate something potentially dire, not making noise about a preference.
Regards, Clay 2010/12/2 Chris Nighswonger <cnighswon...@foundations.edu> > CC'ing the dev list.... > > > On Thu, Dec 2, 2010 at 11:16 AM, Liz Rea <l...@nekls.org> wrote: > On Thu, Dec 2, 2010 at 9:39 AM, Chris Nighswonger < > cnighswon...@foundations.edu> wrote: > >> On Thu, Dec 2, 2010 at 9:48 AM, Liz Rea <l...@nekls.org> wrote: >> >>> Backing down the version to 2.0301 to match the Lenny available package. >>> >> >> Hmm... 2.05 is the newest version of this module in cpan. I think >> Makefile.PL should always ask for what is truly the newest version rather >> than being tied to a particular distribution. >> >> my $0.02 worth >> >> Kind Regards, >> Chris >> > > > >> I did actually think about this before I did it. :) >> >> I asked around if it would be better to update the documentation to take >> the package out of the install script and add it to the CPAN list, or do >> what I did, and the general consensus was that backing down the required >> version was a better option (since the newer version doesn't add any >> functionality that we actually use), so I did that. >> >> The reason is that a lot of people use Lenny (and or Ubuntu, which would >> cause this same issue), and Squeeze/Sid aren't stable yet (even though they >> work fine, I know that). Every indication I've gotten is that "we" prefer >> packaged versions of things instead of pulling direct from CPAN. I chose to >> eliminate the error message when installing on Lenny/Ubuntu from >> Makefile.PL, and allow a required version that was lower than the current >> version to help eliminate a bad user experience (An error!!! OMG! What do I >> do!). >> >> I truly don't care which way it's done: we can remove it from the package >> script and add it to the modules requiring installation through CPAN, no >> problem. I'll do those patches too, if necessary. >> >> That said, I don't think the reasoning behind this particular patch is >> unsound, based on past precedent. >> > > I'm not familiar with what has been the rule in the past. However, it is my > opinion we should establish one standard rather than attempting to work > around two different ones. > > If we are going to take the Debian/Ubuntu repo version as the standard, we > should set all modules available in those repos to the max current version > available in those repos, and be sure that policy is clear in the docs. We > should also develop only over those currently available versions. (I realize > in this particular case there is no programmatically compelling reason to > use the latest version, but that is not always the case.) > > FWIW, I favor Debian/Ubuntu personally, but am concerned about this from a > policy standpoint. > > If we indeed see this as the best direction to go, I recommend we add > something like this to our coding guidelines: When/Where available, Koha > Perl dependencies should be sourced from the current stable Debian/Ubuntu > repository. Perl dependencies not available in the repository should be > sourced from CPAN. Code development should be limited to the most current > version available from the proper source. Exceptions to this policy may be > made by gaining consensus from the developer section of the community. > > or some such language... > > Kind Regards, > Chris > > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ >
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
