Discussion notes on WebUI release process from Dec 21

[daviddias]

• In order to support the multitude of webui + js-ipfs-api versions and to suport fast update on already released IPFS versions, we will
• have webui.ipfs.name pointing to the latest hash of webui
  have webui-0310.ipfs.name pointing to the hash respective to webui for 0.3.10 (and other subdomains for respective hashes of other versions)
• each published version is tagged on github
• we only support bug fixes and new features in latest
• we need tests (really, webui is so old, go-ipfs should have integration tests before it is released)

[RichardLitt]

@diasdavid Are these todos? Or notes from a talk? What's actionable?

[travisperson]

When you say webui for 0.3.10, are you meaning go-ipfs 0.3.10? I feel it's important to hammer out the API completely and then have go-ipfs and js-ipfs implement an API version, after that you have a webui built to the spec of the API so that it can work on either go-ipfs or js-ipfs.

This of course might happen down the road, as I'm sure it will be a while before js-ipfs is at a point where it will be feature ready for a webui.

[daviddias]

To avoid breaking the WebUI for users, there are several things that need to be aligned, namely: ipfs daemon, js-ipfs-api and webui. Using always "latest" won't work for older versions IPFS, unless we keep code around for retrocompatibility (and a lot of if/else for edge case conditions).

What we are trying to achieve is to have a way that we can update the webui for our users (specially early adopters of consequent releases), so we can get feedback on those developments. Right now, the WebUI gets updated by changing the hash that is hard coded in go-ipfs.

Since IPNS doesn't support yet multiple IPNS records, we can use DNS in our favour to have several mutable pointers for the several versions of the WebUI.

What this translates to is something along the following lines (from what has been discussed and complemented in yesterday's sprint meeting):

• On each ipfs release, create a TXT record on webui.ipfs.name with : and once that is fetched, cache it locally so that it can be resolved in disconnected envinroments
• On ipfs master branch, we keep the resolution to master: , for testing purposes and deployment
• extra idea: We can add dropdown list on the webui (which gets filled by resolving /ipns/webui.ipfs.io) the available hashes of webui so that we can change them through the interface

@RichardLitt on what is actionable, now it is about getting some thumbs up from everyone and then making it a part of the release process :)

[RichardLitt]

Cool. Thanks for clarifying! All sounds fine to me.

[olizilla]

It sounds nice to have an update mechanism, but the more I think about it, the more it feels like we'll run into all the edge-cases that you highlighted @diasdavid of incompatibilities between the node, js-ipfs-api version and Web UI version.

I intend to make regular monthly releases of Web UI, and I'll continue the ritual of PRing the new CID to js'n'go-ipfs. In the background we've continuously deploying to webui.ipfs.io so folks in the know can try out the latest features (if they configure the allowed domains headers). So we have 1 bleeding edge thing (webui.ipfs.io), and one stable "should all work together" thing (CID backed into releases)

@diasdavid Do we need a anything else at this stage? It'd be cool to be able to see all the CIDs of previous versions in a dropdown in the UI, and be able to hop between them, but it doesn't feel like a priority right now. It might make a cool demo for the permanent web, which is always worth some time, but I'm just trying to figure out if there is any other motivation for this that I should consider.

[SgtPooki]

Closing this as we have defined release process and will be sticking to it for the foreseeable future