RCs, Dev builds, and nightlies

[jbenet]

There is interest from the community in having builds for:

• RCs
• dev builds (somewhere between a nightly and an RC)
• nightlies

dist.ipfs.io could show nightlies/dev builds, either:

1. as a different "distribution" (go-ipfs-dev), this is easiest to do
2. as an option under each distribution (we'd have to choose whether to do a grid too, and whatnot), or a "channel" (ie chose from {release, RCs, dev, nightly}). It will take some design work and dev work to come up with ideas on how this should look, and then implement it.
   • I think (1) is easiest for go-ipfs in the short term. we could have: go-ipfs-rc, go-ipfs-dev and go-ipfs-nightly as distributions.
   • I think (2) may be the best in the long run, particularly because other distributions will want this type of functionality. Will need to decide:
   • How should channels be represented?
   • as another dir in the hierarchy? (<dist>/<chan>/<ver>/)
   • or as a symlink (it's really a branch, right...)? (<dist>/<chan> -> <dist>/<ver>)
   • or as link values in the dist.json ({ ... "channels": { "<chan>": "<ver>", "release": "0.4.2", "RCs": "0.4.3-rc3", ...} })
   • How should channels show up on the index page? maybe "tabs"? on top of the grid?
   • For now, let's first decide: (1) or (2) in the short term?
   • And then kick off work on (2).

[jbenet]

Carry on discussion on (2) over here: https://github.com/ipfs/distributions/issues/78

[parkan]

Hmm seems like these are really mutable pointers/branches that point to "versions" which themselves may or may not be fixed to a commit?

[jbenet]

• well even the versions are just pointers to some directory, right? like, everything is just a "name" -> <hash>. they're implemented differently of course, but at the end of the day that's what's behind them
• all of these, {versions, channel, ...} will have a git tag/branch (git named ref) which is the same thing: a string mapping to a hash (merkle web \o/)
• and yeah versions are fixed to a commit