Version Control - GitHub and CPAN

[Bod]

More Monastic Wisdom is rubbing off on me...I am uploading (git committing?) AI::Embedding following nudges from hippo and others, but especially GrandFather in Re^3: What is ignore.txt

Questions as usual...

1 - Is there a convention I should be using for naming Perl repositories?
I have looked at others and some start p5-... - I assume that was to distinguish them from Perl 4 but is that a concern now? Others use perl-... and others just the name of the module. Is there a preferred way to do it that I should follow?

2 - Am I right that GitHub and CPAN are not connected?
There is no means for changes within GitHub to be reflected on CPAN other than by uploading a tarball in the usual way. GitHub is "just" (hardly "just" but I hope you understand!) a place to store, collaborate and develop code. CPAN is the repository where it gets installed to.

3 - Should I have different GitHub accounts for different purposes?
In time I will be releasing a JavaScript library for one of my businesses (On Radar) to allow web developers to interact with our CRM product. If this ends up on GitHub does it need a different account? If so, is it because it is for the business or because it is in a different language?

I understand the value but also want to do it right. I've had a few people contact me with suggestions for Business::Stripe::WebCheckout, some have sent useful code snippets that have been included or will be included in a later release. Surprising as I didn't really think anyone would find it useful! If it were on GitHub like it will be, they could have done a pull request and I wouldn't have to insert their code...just approve the PR and build a new release periodically :)

[hippo]

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.

[Bod]

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?

[choroba]

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

[hippo]

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.

[hv]

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.

[Bod]

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?

[hv]

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.

[swl]

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.