http://qs321.pair.com?node_id=11128025

Lotus1 has asked for the wisdom of the Perl Monks concerning the following question:

I'm using mbtiny and Minilla to build and release my module to github and CPAN. I've been reading (and re-reading) Minilla::Tutorial and App-ModuleBuildTiny to figure out how to use these tools.

I noticed that the new version of my upload to CPAN wasn't showing up as the latest version. I found that the newest version of meta.yml has the old version as the latest. I found the problem is that meta.yml is generated by mbtiny but then when I run minil release it prompts me to bump up the version. That means meta.yml doesn't get bumped up to the new rev and shows the old revision as the latest.

My solution for now is to run minil release a second time without increasing the revision. Minilla has to have a comment for the new rev in the changes file but it doesn't require an actual increase in the revision level to do the release.

I'm wondering if there is a way to get Minilla to run mbtiny after the rev is bumped up. Does anyone here have experience with Minilla and mbtiny? Is there an easier alternative to these two?

Update: My workaround of releasing a second time without bumping up the version doesn't work.

Replies are listed 'Best First'.
Re: mbtiny and Minilla workflow - one rev behind in CPAN
by 1nickt (Canon) on Feb 07, 2021 at 19:20 UTC

    Hi,

    "Is there an easier alternative to these two?"

    I can't say whether it's easier, not having used your toolkit, but I am a big fan of Dist::Zilla. Yes it is intimidating at first glance and you'd have a steeep learning curve if trying to go from scratch with the doc (as I once did) ... but there's no need to with the many great examples of .ini files out there. My own now very stable one is based on David A Golden's. You're welcome to copy it as I did his.

    With the ini file I've developed, my workflow for a new release is very painless and fast. I just have to commit the work and a Change note and run the program; versioning bumping, git tagging and pushing, etc all rolled in. The distribution ships with a standard Makefile.

    I see a lot of threads about distro release/build woes, and most often folks eschew the D::Z option because of perceived diffculty. It's nothing but smooth sailing for me :-)

    Hope this helps!


    The way forward always starts with a minimal test.
[reply]
[d/l]
[select]

      I had read that Dist::Zilla is more for people who do releases everyday. Where can I find your ini file? It sounds like a good option.

[reply]

        Most recent example here. Also requires the weaver.ini file which adds Author, Copyright etc to the Pod for modules.

        Have fun!


        The way forward always starts with a minimal test.
[reply]
[d/l]
Re: mbtiny and Minilla workflow - one rev behind in CPAN
by Arunbear (Prior) on Feb 08, 2021 at 11:17 UTC
    I've used Minilla for a few of my modules, but had never heard of mbtiny. What benefit does mbtiny give you / can you do without it?
[reply]

      I'm using mbtiny to generate these files: Build.PL, MANIFEST, META.json, and META.yml. If Minilla will handle those then I could drop mbtiny. Maybe I'm causing more problems with including META.yml since it seems to be just for legacy tools. I'll see if I can figure that out.

[reply]
        Minilla did generate all of those for my modules. Build.PL and META.json were generated by "minil new", and the other two by "minil release".
[reply]

Back to Seekers of Perl Wisdom