Re^3: testing/release advice [was: Stopping tests]

The meaning of "first" is my quibble. If by "first", you mean "before I've done a initial public release", I have no problem with that (though I've never done that on my handful of CPAN modules, and don't remember seeing that advice). If by "first" you mean "before I've thoroughly tested my distribution", I would vehemently disagree with that understanding. :-)

By "first" I mean after testing but before the public release...
However, until today, I wasn't aware that I could test a module in multiple environments other than spinning up a virtual environment. Given that this module is both passing and failing on Linux under the same version of Perl according to the test results, I figured I would have to spin up so many variations that it would be impossible, or at least impractical. Compounded by my servere lack of in-depth Linux knowledge.

Those who want a pre-release can install a pre-production module from GitHub, it doesn't have to be on CPAN for that.

The module was released to CPAN before it was uploaded to GitHub. Other than for Pull Requests, I've yet to see how GitHub is useful for Perl as people install them from CPAN. Given the number of Monks who use it and have advised me to do the same, I total accept it's the right way to go but I don't totally understand why yet.

I tend to do the development locally, test through example scripts, test through test files and prove them. Package and upload to CPAN then think about GitHub a few days later!

I vaguely remember being highly curious why you needed to do that, the last time you mentioned it, but didn't have time at that point to look into it, and I had probably hoped that someone else would disabuse you of that need.

I copy the META files because that's what's it says to do in Re: What do I use to release a module to CPAN for the first time?

Like I said earlier, I don't understand why I copy them or what they do. I really should but there is always something more pressing and, as it works, it is low priority to find out why it works...

Merge the CI environment I gave in the PR, and watch it fail

I've merged the META_MERGE Pull Request. My first time dealing with a PR from that end...I did one on Module::Starter under the excellent guidance of hippo but then heard nothing more. I'm looking at the CI PR now and will try to understand what it does and what I do with it!

I feel really weird giving advice like this. I'm just an amateur with a few CPAN modules that, as far as I know, no one but me uses (okay, I know of one other user of one of my modules, but one real user is statistically zero compared to CPAN norms). I'm not sure why anyone would trust any of my advice. And I definitely make no claim that it's "best practices".

I learnt a long time ago that you don't need to be very much further ahead to give valuable advice. Many times it's better if you are not too far further down the learning road as you haven't forgotten the challenges everyone goes through. Regardless of how weird you feel, your help is very much appreciated 👍

Comment on Re^3: testing/release advice [was: Stopping tests] Select or Download Code

Replies are listed 'Best First'.
Re^4: testing/release advice [was: Stopping tests] by stevieb (Canon) on Sep 14, 2023 at 12:43 UTC
Other than for Pull Requests, I've yet to see how GitHub is useful for Perl as people install them from CPAN. Given the number of Monks who use it and have advised me to do the same, I total accept it's the right way to go but I don't totally understand why yet. It's exceptionally useful. It allows us to fork and clone your project and review/modify/test it locally, in our own environments. It's far less time consuming then downloading a tarball, extracting it, playing with it, then creating patches to send you for possible inclusion. You seem to be in the mindset that devs just want to install your software. We don't. Often we don't want to install it at all, just want to look at it. Also, as pryrt mentioned above, you get Github Actions to perform automated CI testing on every push to the repo. This is infinitely handy. (A couple of years ago I switched all of my projects to Github Actions from Travis CI). It also allows you to easily revert changes, find when specific changes were made (and by who), run multiple concurrent branches simultaneously then merge the changes from those branches into your main branch once they're tested and stable etc. The version control system is far more useful to yourself than it is outside users of your software, but it is very useful to them too, regardless of the language in use. Your workflow should begin with the Version Control System, not be an afterthought. Once you've gotten into this workflow process, you'll begin to clearly see how and why it is so important. Update: Here's one of my basic Github Actions configuration files. It's a file called `.github/workflows/github_ci_default.yml` in the root of one of my repositories. Do some reading on Github Actions. It'll be worth your time.	[reply] [d/l]

Replies are listed 'Best First'.

Re^4: testing/release advice [was: Stopping tests]
by stevieb (Canon) on Sep 14, 2023 at 12:43 UTC

Other than for Pull Requests, I've yet to see how GitHub is useful for Perl as people install them from CPAN. Given the number of Monks who use it and have advised me to do the same, I total accept it's the right way to go but I don't totally understand why yet.

It's exceptionally useful. It allows us to fork and clone your project and review/modify/test it locally, in our own environments. It's far less time consuming then downloading a tarball, extracting it, playing with it, then creating patches to send you for possible inclusion. You seem to be in the mindset that devs just want to install your software. We don't. Often we don't want to install it at all, just want to look at it.

Also, as pryrt mentioned above, you get Github Actions to perform automated CI testing on every push to the repo. This is infinitely handy. (A couple of years ago I switched all of my projects to Github Actions from Travis CI). It also allows you to easily revert changes, find when specific changes were made (and by who), run multiple concurrent branches simultaneously then merge the changes from those branches into your main branch once they're tested and stable etc. The version control system is far more useful to yourself than it is outside users of your software, but it is very useful to them too, regardless of the language in use.

Your workflow should begin with the Version Control System, not be an afterthought. Once you've gotten into this workflow process, you'll begin to clearly see how and why it is so important.

Update: Here's one of my basic Github Actions configuration files. It's a file called .github/workflows/github_ci_default.yml in the root of one of my repositories. Do some reading on Github Actions. It'll be worth your time.

[reply]
[d/l]