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.

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?

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]

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.

---

🦛

1. Your repositories belong to you, the naming is up to you. A perl- or p5- prefix sounds more like the sort of thing I'd expect for OS packages.

A typical place to see repository names is at the landing page for an author (like mine) or the repository list (like repositories); as you will see from those examples, I tend to prefer short repository names, but try to augment them with an at least somewhat useful description.

When you go to a specific repository, github will try to find a top-level README (plain text) or README.md ("github markdown") to show, as at krun. This is where you can go much further to help a casual browser understand whether this is the repository they are looking for.

2. I don't know of any such connection, but I'm sure enough people are now using git as the revision control system for their CPAN code that someone (several someones) will have automated the process of releasing to CPAN from git. In that respect, github would likely be no more than "just another git repository" - the automation would most likely use git commands directly.

3. I never saw any reason to have multiple github accounts myself. I can't think of any technical reason to want them, but there are possible social reasons: perhaps because you work for a company that likes to claim copyright in things employees do in their own time; or because you feel the type of code you write in your own time risks reflecting badly on you professionally.

Next question...

With a module like AI::Embedding, there are 4 development releases and 2 production releases...

Is it worth uploading all the previous releases to GitHub or should I start with the latest release and rely on the CHANGES file to know what went before?

When I've done this sort of thing in the past - moved code into a revision control system after already having released several versions - I've made the first few commits represent the released versions. From time to time it can be really helpful to use the revision control system's capabilities to look at when a particular line of code was first introduced, eg using git blame. Be careful if you do this to check for new files - it is easy to forget to add them.

Whether it is also worth making the packaged-up releases of previous versions available via github I don't know - traditionally people would get such things from CPAN or BackPAN, but perhaps there is now a new generation of users more familiar with github than with CPAN that might make use of such things.

It's worth having a look at gitpan. It has not been updated recently so does not track your module, but it should be possible to adapt the code.