git migration

classic Classic list List threaded Threaded
41 messages Options
Reply | Threaded
Open this post in threaded view

git migration / going Zenodo

"Peter Löwe"
Hi Markus, PSC,
apologies for following up on this so late.
The grass-legacy structure in GitHub is fine, of course.
Regarding the options how to integrate with Zenodo, I believe we're on the right track. There is an alternative option by manual/Zebodo-API-based integration, but I don't believe this makes sense. All feedback from the Zenodo helpdesk on this has been included in the "future plans" section of the wiki page:
Gesendet: Mittwoch, 17. April 2019 um 16:29 Uhr
Von: "Markus Neteler" <[hidden email]>
An: "\"Peter Löwe\" ([hidden email])" <[hidden email]>
Cc: GRASS-PSC <[hidden email]>
Betreff: Re: git migration: Zenodo and versioned DOI for GRASS releases
Hi Peter,
"Peter Löwe" <[hidden email]> schrieb am Mi., 17. Apr. 2019, 12:15:
Hi Markus, hi PSC,

the reason why I believe we should consider the Zenodo option (for long term archiving and DOI-based scientific recognition/citation) before making the switch to GitHub is the DOI versioning capability of Zenodo ( This is similar to the mechanism implented for the GRASS module manual pages, where references from outdated versions point to the current release of the module (and man page). The DOI-versioning mechanism in Zenodo additionally implements a version history as a hsitorical sequence of releases. This means that the DOI version for GRASS 4.2.1 predates GRASS 4.3, which predates GRASS5.x, etc. etc. and all also point to the latest release.
Yes: each release is a point in time.
The GRASS SVN contains the release branches dating back to GRASS 5. In addition there are tarballs from the GRASS 4.x era (-> what about GRASS 3.x or earlier ?).
Please check our work already done:
I have reconstructed the releases back to 3.2 including time stamps at file level.
Note that the URL will change to OSGeo organization soon.
Making all these releases available for scientific citation (and recognition) through one versioned DOI in the described "timely sequence" is a more complex task than what's covered in the how-to guides for GitHub-Zenodo-integration (
We have all branches there, since 1987.
I've contacted the Zenodo helpdesk for advice how this should be approached and will report back ASAP.

It would be a pity (and waste of ressources) if we make the effort to create a GitHub repo for GRASS once and then having to redo it because of some pecularities of the DOI-versioning mechanism.
Still I don't see why we should redo it.
Does the new structure not address it?
Did you check it?

grass-psc mailing list
[hidden email]