Support free-form version field

[hsanjuan]

It seems https://github.com/whyrusleeping/gx/blob/c4842b868f7fadb51b5bd7c75adde71ed461f58f/bin/check_version does a lot of checks on how version looks like.

When gx-ifying Go packages, they usually don't adhere to Semantic Versioning. It would be useful to use the Version field instead to provide a commit hash that indicates from which commit in the original repository the package was created from. This is super useful if someone needs to re-publish a package. i.e. when packages.json includes something like:

    {
      "author": "ugorji",
      "hash": "QmRpRGNbrm6aaU7bnt6AwcJCfyETkdJzmtBdCazMYKoMux",
      "name": "go-codec",
      "version": "0.0.1"
    }

vs.

    {
      "author": "ugorji",
      "hash": "QmRpRGNbrm6aaU7bnt6AwcJCfyETkdJzmtBdCazMYKoMux",
      "name": "go-codec",
      "version": "5f09c4f"
    }

In the second case it is very clear from which point of time this dependency was generated.

gx release <insert custom string> should then also work.

[Kubuxu]

When releasing new package version or gxifying package you can add some file, I usually am adding .git-head file to the root package directory with git rev-parse HEAD > .git-head.

This isn't the best solution but it works.

[hsanjuan]

Thanks, it's a good idea, but if you cannot fetch the hash... still no idea of when it was built.

[rht]

still no idea of when it was built.

This (the timestamp) could be built into DAG itself. Being able to include unixfs permission, timestamp, mimetype, (and maybe author) will solve lots of issue regarding with ipfs integration.

If no one currently in the sprint is doing this, I could be assigned for baking the metadata into the store.

e1: clarify the first statement

[hsanjuan]

@rht same problem, if you only have the hash, but the content is not available on ipfs anymore, you still cannot know when it was built to recreate that hash...

[rht]

ic what you need -- a gx's package.json does not provide the recipe / sufficient info to reproduce/verify its hash.

[rht]

IMO publish/register should mean it remains available (either kept alive by the maintainer or by a pin service), and replicated only through the hash.

[ozra]

Semver is important. If re-packaging packages (woo), perhaps it could be good with "version" (adhere to semver) and "upstream-version" or similar to keep everything in the clear and add a quality assurance on top (provided the re-packager takes the time to evaluate which bumps should be done on the project.. there's always the human factor)

{
   "author": "alice",
   "hash": "QmRpRGNbrm6aaU7bnt6AwcJCfyETkdJzmtBdCazMYKoMux",
   "name": "ox-mooo",
   "version": "0.1.2",
   "upstreamReference": "5f09c4f"
}

[whyrusleeping]

I'm not against adding an upstream reference field to the package.json, we just have to make sure its done in a way that isnt confusing. The biggest problem currently is hash linking. I cant have a package whose package.json contains the git sha that contains the package i published. Currently, i've just been using git as the grand source of truth, meaning you should be able to find any commit where the .gx/lastpubver was updated, and re-run gx publish there to regenerate the package

[hsanjuan]

@whyrusleeping the way you mention works when the dvcsimport leads to the gx'ed repository. But the way I have been doing this is fork a repositry, init Gx, and set dvcsimport to the original official repo so gx-go --rewrite replaces the imports from the official repo (rather than switching those to the fork).

Which means that the user cannot go to the official project source to see lastpubver because that is in the fork. However there is no information about where that fork lives. If the hash is no longer available in ipfs, the user cannot find the information needed to recreate the hash by his/her own means. That's the essence of my problem.