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

After 15 years of writing Perl, I've finally achieved something that I've wanted for a very long time... a module that allows you to inject code into subroutines, and add subs on the fly to files. The original purpose of this was to add a call to a stack trace method to each sub, so a long running program would keep track of its own information.

I'm days away from releasing candidate one of the upgraded module, and I'll be requesting of the Monks who have some time to spare to review the README for too much/too little info, and if they are so kind, to test out the code examples provided in the SYNOPSIS (and beyond).

What I'd like to do is see how it looks after the CPAN parser does its job.

My question is this: Can I upload a devel version to PAUSE (a devel version in CPAN is one that has a _NN designation at the end of the version info) without pissing all over my existing relatively stable version, and view it all the same, while current users will still pull stable in a cpan install Module::Name?.

I could try it, but I felt it better to ask than to put undue load on the CPAN servers.

-stevieb

For those curious, current code can be found in the 'engine' branch here: DES.

Replies are listed 'Best First'.
Re: Uploading a devel version to PAUSE
by jeffa (Bishop) on Jul 23, 2015 at 17:01 UTC

    While i do make mistakes when i upload a new release to CPAN, i do not upload development releases. The reason is because i have other tools to handle the items you listed out:

      1. travis-ci will run smoke tests across several perls every time i push changes to my github repo
      2. jenkins requires more work, but i find it invaluable to building my distros. Between travis-ci and my jenkins installation, i can get a very good idea at the quality of the current state of my distribution.
      3. perlbrew is now more important to me than use strict. We'll come back to it later ...
      4. cpanm allows me to install and uninstall the distros that i build via Jenkins. I configure Jenkins to make a successful build's tarball available for downloading via a URI. I can install this tarball directly with cpanm and see if there are any unexpected problems. Clean up is a breeze via cpanm -U.

    So now i have a pretty good infrastructure set up to catch blunders i make: i should have commit hooks that will only fire when all tests pass, but i am pretty good at making sure tests pass before i commit code. I can browse travis-ci and make sure nothing is red: perhaps i added a dependency that an older perl didn't have or a newer one no longer ships with, etc. I can access my Jenkins server and build a test distro. I also use pod2html to make document artifacts that give me a decent approximation of how CPAN sites will format them. I can use perlbrew to switch to a clean perl distro and see how long it takes to install my module from scratch via cpanm.

    Finally, after several days have passed since i uploaded a new version, i can check the CPANTS reports which is more exhaustive than my setup. I can recreate any test failures by installing that version of perl (thank you perlbrew) and running my tests against it. For example, i finally fixed this long running issue. (And so far ... so good.)

    In summary, i do not want to give the impression that development releases are in anyway prohibited at CPAN. Quite the opposite. I just happened to acquire some skills to allow me to handle those issue you listed out before i upload to CPAN. Hope this helps. :)

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
[reply]

      Thanks jeffa, that's some great feedback.

[reply]
Re: Uploading a devel version to PAUSE
by 1nickt (Canon) on Jul 23, 2015 at 13:42 UTC
    <RANT>

    Well, it seems that these days one can upload anything to PAUSE. Your personal Dist::Zilla dist.ini file? A CPAN module. Your favorite CPAN modules in a bundle? A CPAN module. A completely empty shell of a module (yes, I'm talking about you, DCONWAY)? A CPAN module. An app you wrote for your enterprise? A CPAN module.

    Pretty soon it will be CPAM !

    </RANT>

    Ah, thank you, I feel better now.

    As to your question about uploading a DEVEL version to CPAN; plenty of people do that all the time. What I wonder is: Why? Not trying to be snarky; I really don't know why one would upload code to CPAN that one didn't think was production-ready. Please enlighten me, as I am sure you have a good reason that is simply escaping me.

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

      For a few reasons:

      - see how my POD formatting looks after CPAN renders it
- get an idea of how my tests are performing
- allow testers to fetch from CPAN as opposed to download/install
- test dependency issues
- test any custom installation tasks in an automated install

      [download]

      I don't plan on uploading anything until I'm comfortable with everything I said in the POD is true (ie. I have a couple of features to finish off), and beyond that, some of the examples I currently use in SYNOPSIS will change significantly due to new efficiencies/ease-of-use features I'm finishing up.

[reply]
[d/l]
      Mostly so that other people can check the new code, preview features and send feedback.

      Getting into the CPAN Testers wheel is pretty useful too.

[reply]
      I mostly do that because I do my devel/test in Linux only and with a specific perl, while CPAN Testers have a much broader selection of OSs and Perl versions. When things are fine in CPAN Testers I then usually release the distribution, but many times I get notifications of things not working correctly (mostly due to Windows) and I can patch before releasing.

      perl -ple'$_=reverse' <<<ti.xittelop@oivalf

      Io ho capito... ma tu che hai detto?
[reply]
Re: Uploading a devel version to PAUSE
by Anonymous Monk on Jul 23, 2015 at 01:02 UTC
    Yes, thats what devel versions are supposed to do
[reply]

Back to Seekers of Perl Wisdom