in reply to Re^5: (solved) Clean smoke-test install for Inline based modules using Inline::MakeMaker
in thread Clean smoke-test install for Inline based modules using Inline::MakeMaker

It definitely should be Inline::MakeMaker.

Good !

..but Inline::MakeMaker, included with that dist. is v0.45

Yes, I always make sure that the Inline.pm and Inline/C.pm version numbers match the version number of the Inline distro, but I haven't bothered updating the version numbers of any of the other pm files that ship with Inline. Does it matter ? (Looking back, it seems that Ingy did keep the Inline::MakeMaker version number in tune with the Inline distro number.)
Naturally, if I ever alter Inline::MakeMaker I'd change the version number. (At least, I'd hope that I remember to do that - I see that I've altered it once already, and did bump the version number on that occasion.)

Inline/C/ParseRecDescent.pm, Inline/C/ParseRegExp.pm and Inline/denter.pm don't even have version numbers - yet may have been modified in the past. I last made alterations to ParseRegExp.pm and ParseRecDescent.pm back in March 2010 .... didn't think to give them a version number at the time ... something to keep in mind in the future.

In fact I could probably assign the same version number to all of the pm files that ship with Inline, if that's the expected thing to do. (It shouldn't stress me too much :-)

Cheers,
Rob
  • Comment on Re^6: (solved) Clean smoke-test install for Inline based modules using Inline::MakeMaker

Replies are listed 'Best First'.
Re^7: (solved) Clean smoke-test install for Inline based modules using Inline::MakeMaker
by davido (Cardinal) on Dec 16, 2011 at 06:50 UTC

    It's certainly not necessary for all modules in a distribution to have the same version number, but where the two modules I'm most familiar with (Inline, and Inline::C) do match, I mistakenly assumed that Inline::MakeMaker would as well, and nearly made the mistake of specifying CONFIGURE_REQUIRES => { Inline::MakeMaker => 0.49 }

    Ok, actually I did make the mistake, but the output from make was loud enough for me to realize the error before attempting to make test, and make dist. :)

    I wouldn't worry about it. Now that I know it's not just an oversight I will sleep just fine tonight.... if it weren't for the other issues (.h, no .h) I can't seem to let go of. haha


    Dave

Re^7: (solved) Clean smoke-test install for Inline based modules using Inline::MakeMaker
by GrandFather (Saint) on Dec 16, 2011 at 07:16 UTC

    I'd consider it in terms of release cycle. If all the modules have the same release cycle I'd be strongly inclined to use the same version number. If the release cycles for the individual modules are sensibly disjoint I'd be inclined to use different version numbers. However if the modules are related (by API definition perhaps) but may have disjoint release cycles I'd use a major.minor.point version number scheme where interface changes imply at least a matching minor version bump across the suite and point bumps for individual module releases.

    True laziness is hard work