Re^3: Using a Single Point of Truth for $VERSION in a distribution?

Hi again jcb.

The remark about people fearful of learning curves had to do with the large number of negative opinions about dzil you'll hear (from people who don't use it) ... not directed at you.

"then I firmly believe that they should actually alias that value to make it obvious that they do not have independent versions. Perl understands this, but the CPAN indexer does not."

"If I put separate $VERSION literals in each module, I want them updated if and only if that module has been changed since its version was last updated."

I'm afraid I'm less clear now about what you want. The second statement seems to contradict the goal implied by the first, namely that the non-primary modules should always carry the same version as the primary one. The second statement seems to imply that the different modules would/could have differing versions. It's up to you how to do it, but from what I've observed there's a lot less maintenance for the distro author if all the modules get their version number bumped together than trying to ensure that the right dependency versions are required in the build specs.

Here's the dzil tutorial on version numbering. It addresses just the case where all modules in your distro have the same version number, showing a few plugins to do that in different ways.

There are two-and-a-half pages of results for a metaCPAN search for 'Dist::Zilla::Plugin::Version' so I'll let you browse through them. Do your due diligence -- lots of people of varying abilities write dzil plugins. A useful technique is to look at the dist.ini of distros you admire.

I have done no such due diligence on Dist::Zilla::Plugin::SurgicalPkgVersion but it seems to do what I think you meant by your second comment cited above ;-)

Hope this helps!

The way forward always starts with a minimal test.

Comment on Re^3: Using a Single Point of Truth for $VERSION in a distribution? Download Code

Replies are listed 'Best First'.
Re^4: Using a Single Point of Truth for $VERSION in a distribution? by jcb (Parson) on Apr 19, 2020 at 03:33 UTC
I have now had time to read the `Dist::Zilla` tutorial and after checking its dependencies, I believe that I will have to pass on `dzil` for now. To use a term I have seen elsewhere in the Monastery, my conclusion was ETOOMUCHMAGIC. `Dist::Zilla` seems to be the type of tool that I have had problems with in the past, being elegant, complex, powerful, — and fragile. It will work and it will work very well and the details of making it work will be forgotten. Then a future upgrade will break something. I have had to handle systems like that at $WORK in the past and I prefer simpler answers for my hobbies, but that is my preference and you are of course free to enjoy the power while it works. :-)	[reply] [d/l] [select]
Re^5: Using a Single Point of Truth for $VERSION in a distribution? by NERDVANA (Priest) on Apr 20, 2020 at 17:29 UTC
Dist::Zilla is complicated and has a learning curve, but actually once you get it configured the way you like you can forget most of the details and just copy the dist.ini from one project to the next, making a few changes as needed. Language::FormulaEngine dist.ini Geo::SpatialDB dist.ini Elf::Writer dist.ini (notice how in the source for FormulaEngine I just add a `#VERSION` comment and `dzil build` inserts the incremented version from the last git tag.) I totally agree with the sentiment you are expressing about not wanting to waste tooling time on a personal project, but this one really will pay for itself if you release a few modules. I wish Dist::Zilla was not written as a giant pile of heavyweight Moose roles, but the external design is absolutely correct (running "dzil test", "dzil build", "dzil release" and so on) and I have been able to make all the customizations I've needed even for some wild makefile requirements: Data::TableReader dist.ini weaver.ini (example adding "Contributors" POD section auto-generated from Git) VideoLAN::LibVLC dist.ini Makefile.header (example of exotic c-library detection using MakeMaker::Awesome plugin) OpenGL::Sandbox dist.ini (example using Inline::Module plugin to distribute a module using Inline::C as a standard XS module not depending on Inline)	[reply] [d/l] [select]