Difference between revisions of "Best practices using metadata"

From Software Heritage Wiki
Jump to: navigation, search
 
Line 33: Line 33:
 
|package.json, [ AUTHORS, README, CHANGES, LICENSE & NOTICE] files
 
|package.json, [ AUTHORS, README, CHANGES, LICENSE & NOTICE] files
 
|yes
 
|yes
|no
+
|yes
 
|-
 
|-
 
|Perl CPAN::META
 
|Perl CPAN::META
Line 68: Line 68:
 
|CODE, code.json, codemeta.json
 
|CODE, code.json, codemeta.json
 
|yes
 
|yes
|no
+
|yes
 
|-
 
|-
 
|Java gradle   
 
|Java gradle   

Latest revision as of 13:33, 24 October 2017


1. Use a detailed metadata file with name appropriate to context as listed bellow :

context filename in CodeMeta crosswalk table implemented for swh translation
java- Maven pom.xml yes no
Octave DESCRIPTION yes no
R package DESCRIPTION yes no
ruby gems .gemspec or Rakefile yes no
Javascript npm package.json, [ AUTHORS, README, CHANGES, LICENSE & NOTICE] files yes yes
Perl CPAN::META META.json, META.yml, .sDpec yes no
Dart pubspec.yaml no no
Debian package debian/upstream/metadata yes no
puppet metadata.json no no
PyPI setup.py yes no
Scientific software CITATION no no
CodeMeta CODE, code.json, codemeta.json yes yes
Java gradle gradle.properties no no
Jekyll _config.yml no no
clojure project.clj or build.boot no no
haskell <project name>.cabal no no
scala build.sbt no no
Ocaml opam no no

2. Use Semantic Versioning [1] for reproducibility purposes.