Update versioning schedule to immediately deprecate alpha version?

[michielbdejong]

According to https://github.com/interledger/interledger/wiki/Interledger-over-CLP#versioning, version 1 (which uses BTP version alpha), should be supported by all testnet nodes until end of June, and version 2, which uses BTP version 1, should be supported during all of 2018.

Therefore, from January to June, testnet nodes require software that supports both BTP version alpha and BTP version 1.

Both @emschwartz and @sharafian asked why we don't deprecate the alpha version of BTP with immediate effect, so I'm opening this issue to discuss that option.

[michielbdejong]

Answer, IMHO, definitely not. The versioning schedule is there to create a stable dev experience, and we agreed that that's important, and that we're underperforming on that goal.

I see two reasons why we might want to deprecate BTP-alpha earlier:

• in a two-overlap versioning scheme, each node, at any given time, only supports versions k and k+1, meaning we can't deploy BTP/2.0 earier than July 2018. However, I don't think anybody would want to deprecate BTP-alpha for this reason, since the current hope is that BTP/1.0 will be more than fit for all our needs until probably later, rather than earlier, than July 2018.
• if we start off the testnet with just BTP/1.0 instead of both BTP/alpha and BTP/1.0, it will be easier for developers to write a fully functional testnet node, because (at least during those first months) they only have to worry about one BTP version. This will not be relevant for applications written in JavaScript, but it will be, for applications written in other languages, such as Rust or Python.

To cater for the needs of this last group of developers, I'll publish a BTP/1.0 <-> BTP/alpha proxy, which they can put in front of their deployed node, in case someone wants to peer with a them, and does not support BTP/1.0 yet. That way, even Interledger implementations that do not natively support BTP/alpha can still claim to be testnet-compatible, by pointing to that proxy.

[emschwartz]

I feel pretty strongly that we should deprecate BTP-alpha as soon as BTP/1.0 is decided upon and implemented.

Reasons:

1. There are no existing users or implementations outside of our control that we need to support
2. If we want multiple implementations it's far more complicated to implement two versions than just one
3. It's more confusing to have two versions floating around
4. The way we've been trying to develop these protocols is working under the assumption that at some point they'll be as difficult to change as IPv4 (rather than something that has a steady release cycle). Whether or not we want it to be this way, we have a closing window of time when we still can change things without massively breaking the ecosystem and once we say "we're satisfied for now", they'll probably stay roughly the same for 10+ years (assuming the project lasts that long)

[michielbdejong]

I'll think about it some more.

[michielbdejong]

OK, I thought about it, and this is what I came up with:

I'll add multiple endpoints to Amundsen, 4 per year. The first ones will be 17Q3 (the current version) and 17Q4 (the one based on https://github.com/interledger/rfcs/300). Initially, the 17Q4 endpoint will only support the 'auth' and 'ilp' protocols. Then we add protocols one-by-one as Q4 progresses. So this is not about BTP versioning, more about resetting the sub-protocols registry once every quarter.

Amundsen will support each protocol incrementally during its dev phase (the quarter its name refers to), and then in frozen form for at least an additional 3 quarters.

Interledger software can decide to only (ever) support the sub-protocols from the 17Q4 registry, that's fine. They don't need to support multiple versions, only Amundsen, as a bootstrap node, will do so, so that developers will have a guarantee that their demos will not start failing unexpectedly. If you build a 17Q4-based demo now, and it uses the testnet by bootstrapping from Amundsen's 17Q4 end-point, you can trust that it will not start failing until at least 1 October 2018.

The switch from 2 to 4 versions per year is for two reasons:

• if it only applies to Amundsen and not to all other software, it's "cheaper" to do more versions
• in the 2-per-year schedule, people playing around with BTP/1.0 would have to wait until 1 January until they could connect to Amundsen for the first time. We could unofficially make this available earler, but if we say the versions go twice as fast, then the official date is moved forward from 1 January to 1 October, so I thought that's quite nice. Most of this gain is from the fact that will initially only support ilp and auth, and not other protocols like vouch and paychan yet, so that we can still discuss those further during Q4.

[michielbdejong]

Updated, see https://github.com/interledger/interledger/wiki/Interledger-over-BTP#versioning