develooper Front page | perl.perl5.porters | Postings from January 2009


Thread Previous | Thread Next
Sam Vilain
January 5, 2009 12:00
Message ID:
On Mon, 2009-01-05 at 15:09 +0100, demerphq wrote:
> as it lives in git.git has the problem as far as i can tell of
> being bound to the installed version of git, which means that you
> can't use it to implement a workaround layer to make tools version
> independent. You essentially have to mandate a dependency on a version
> of git that you may not be able to change, where you would be able to
> upgrade the perl framework.

Ok, but if it *is* dual-lifed, then there comes a numbering issue.  I
know this is currently moot because IIRC there is no $VERSION defined by
the module.  But if I install version 1.0603 from CPAN and then upstream
releases 1.0604, if 1.0603 had newer changes than 1.0604 then there's a
serious problem.  So I think this means that a version of on CPAN
must exactly correspond to the version in the same numbered version of

I think the answer here is to do both things - provide patches for
inclusion in git.git, and mirror releases on CPAN.

Eg, patches can be provided that fix all of the important issues that
make it difficult to use - the API problem that BooK mentions for
instance.  The fact that VERSION is not set (it should probably be
derived during the build process, like the main binary's VERSION is).

Secondly, a patch which allows 'make dist' to work inside git.git, so
that the maintainer can upload to CPAN as new git versions are released.
This would mean it would make sense to allow patches to that
allow it to implement newer features on older Git versions.

Sound like a plan forward?

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About