in reply to Version Control - GitHub and CPAN

There's no naming convention. Anyone using the p5 prefix will have been doing so to distinguish it from p6 rather than p4, but thankfully that is no longer a concern. I would not fret about the name.

Github and CPAN are not connected. Nor are Gitlab and CPAN. Nor Bitbucket and CPAN. How you store or manage your code prior to release is unimportant for CPAN. The only means of connecting them is with the repository metadata which you can include with your dist when uploaded (see CPAN::Meta::Spec for lots more on this).

I wouldn't have different accounts on any one hub/forge for different purpose. Github has "Organisations" and you can release code in any given organisation to which you belong. That's how I would separate work from hobbyist releases.

🦛

Replies are listed 'Best First'.
Re^2: Version Control - GitHub and CPAN
by Bod (Parson) on Jun 19, 2023 at 18:10 UTC

    Is this the sort of thing you would expect to see?

    Do I need to make a 'release' or 'package'?
    Do they set the point at which development becomes a version?

[reply]
      The common practice is to tag the commit that made it into a release with something like "cpan-1.0.1".

      map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
[reply]
[d/l]
      Is this the sort of thing you would expect to see?

      That looks fine to me :-)

      Do I need to make a 'release' or 'package'?

      On github? No, I would not bother. You have PAUSE and CPAN for that. So long as your repo includes the user-level instructions for obtaining and installing (which it does right there in the README.md) there's no need AFAICS to duplicate the release effort.

      Do they set the point at which development becomes a version?

      Github? No, I cannot see how or why they would.

      🦛

[reply]

In Section Seekers of Perl Wisdom