Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2017-08-28

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:01 idiosyncrat Is there a convenient way to package a dependency into your CPAN package -- that is, copy a version of Marpa::R3 into it, and use that?  Some "path" trickery would be involved at a minimum.  I know that'
00:02 idiosyncrat s kind of against the spirit of CPAN, but it would mean I could deliberately upload a broken Marpa::R3 without breaking KollosX::Languages::Perl::PackUnpack
00:51 ronsavage If by upgraded you mean what end-users are instructed to have available via Makefile.PL, then no, there is no automatic/default upgrading.
00:54 ronsavage For example, Test::Simple (containing the Test::More I user) is at V 1.302086, but I only specify V 1.001002 in the above module's Makefile.PL, as the pre-req. That old version of Test::More which I specify is what I choose to restrict my test requirements to as per help from CPAN Testers, so that they can run my tests without having to upgrade to later, or the latest, versions of Test::Simple.
00:55 ronsavage Indeed, I've had complaints from CPAN Testers that my old habit of installing the latest versions at home, and then specifying those versions in various Makefile.PLs, irritates them.
00:56 idiosyncrat But aren't all the version specifications X.yyyzzz *or later* if you use the default infrastructure?
00:57 ronsavage And as for modules shipped with Perl, e.g. open, strict and warnings, I specify V 0, as recommended to me by Father Chrysostomos.
00:59 ronsavage They are only 'or later' if a user has a later copy already installed. But that does not mean your Makefile.PL will force a later version to be installed just because it's available on CPAN :-).
01:00 idiosyncrat Bottom line what I'm saying is that as long as I am "alpha" new versions might not only be broken, but might be knowingly broken and I might be unwilling to provide a fix in a timely way (other than saying you can figure out a way to go back to a pre-broken version).
01:00 ronsavage There is a problem of course with modules whose later versions involve breaking backwards-compatibility, and that later version /is/ installed. You code which uses to old i/f will have a problem.
01:01 idiosyncrat That's exactly the problem you might have as long as you're dealing with my alphas.
01:02 idiosyncrat I think you've find my alpha's very reliable and I'm glad, but I'm not prepared to guarantee they'll continuously improve -- when I feel that I can, I'll start calling Marpa::R3 beta.
01:02 ronsavage The fact you uploaded versions which have alpha-numbers means the end-user is stuck with the consequences. The alpha status is a msg what patches simply can't be assumed to be on-the-way.
01:04 ronsavage And yes, if my code breaks, I have a problem - as always. In such a case I would re-install an older version of Marpa::R3, until it worked again, and specify only the latest version of Marpa::R3 with which my code worked. As an alpha (yours), any user who installed a later version of yours, and saw my code break, would simply have a choice: Revert Marpa::R3 or delay any further investigation of my code.
01:07 idiosyncrat Am I right that you'd advertise KollosX::Languages::Perl::PackUnpack as also being "alpha"?
01:07 ronsavage Anyway, since you're uneasy, I'll hold off. But I /am/ very tempted to release with the pre-req of 4.001_049, and a comment about possible future breakage.
01:08 idiosyncrat If that's the case sure go ahead.
01:08 ronsavage And I just checked, and using 4.001_049 or 4.001049 behave in exactly the same way, as I expected.
01:09 ronsavage I don't release alphas. What I do is have this line in the docs for all (modern) modules of mine:
01:09 ronsavage Version numbers < 1.00 represent development versions. From 1.00 up, they are production versions.
01:10 ronsavage If you don't think that's a strong enough warning, the other thing I could do is blog on blogs.perl.org about the statuses of our modules, warning early adopters:
01:10 ronsavage Here be Elefants (sort of).
01:11 idiosyncrat I really do have a problem with calling something based on an "alpha", and subject to deliberate breakage with no convenient fix, "production".
01:13 idiosyncrat IIRC I have released modules of mine as production which were based on my own betas, but in that case I was willing to guarantee that I would not allow the beta would not change in a way the broke the downstream module.
01:14 idiosyncrat That turned out to be a real nuisance for doing release management.  I kept my promise to the users, but I think I wound up basically regretting the decision.
01:27 ronsavage OK. I'll postpone any release. That's fine.
01:28 idiosyncrat Good, I think that's best.
01:30 ronsavage It's obviously not a good idea for me to release a prod version depending on an alpha version, so I wouldn't do that. And I an uneasy about releasing any version (in my case < 1.00) so depending, but I did want to tell you what I was thinking......
01:52 ilbot3 joined #marpa
01:52 Topic for #marpa is now Start here: http://savage.net.au/Marpa.html - Code paste/run: https://f.perlbot.pl/#marpa - Jeffrey's Marpa site: http://jeffreykegler.github.io/Marpa-web-site/ - IRC log: http://irclog.perlgeek.de/marpa/today - Youtube channel: https://www.youtube.com/channel/UCYKVfGBtfTqbs1JdYq-dc5g
06:50 ronsavage joined #marpa
09:34 koom joined #marpa
23:00 ronsavage joined #marpa

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary