Remove "next" feature

[sisuresh]

When the "next" feature was initially added, it was used to keep the host compatible with both the current protocol and the next one in development. Since then, we've switched to no longer requiring protocol backwards compatibility in the host, and use multiple protocol specific versions of the host in stellar-core. The xdr in this repo should also be pinned to either the "next" or "curr" XDR depending on where we are at with development, so there's no reason to tie the host's "next" feature with the xdr's "next".

The only current use of this feature is it to be able to run a vnext stellar-core against the host and validate various protocol checks. We should be able to remove the feature and update some of those protocol checks.

[leighmcculloch]

The xdr in this repo should also be pinned to either the "next" or "curr" XDR

I have also been pondering if we could remove next and curr for both the stellar-xdr and the rs-stellar-xdr repos. Do you think we get sufficient benefits out of having the two separate branches, that we couldn't get out of making changes on a shared main branch, and on the off-chance we need to make changes to a previous major release we can release a patch like we do in any other repo?

[sisuresh]

The xdr in this repo should also be pinned to either the "next" or "curr" XDR

I have also been pondering if we could remove next and curr for both the stellar-xdr and the rs-stellar-xdr repos. Do you think we get sufficient benefits out of having the two separate branches, that we couldn't get out of making changes on a shared main branch, and on the off-chance we need to make changes to a previous major release we can release a patch like we do in any other repo?

Yeah I was thinking about this. It's not uncommon for us to make non-protocol xdr changes, but it should still be easy to manage with a single branch. I think splitting xdr made more sense initially because the XDR definitions lived in the core repo.

The one scenario we need to keep in mind is this - both protocol changes A and B are in development, and we decide to ship A but not B. Does this get easier or harder without next? With next, we would just copy A into curr and leave B in next. With main, we would have to erase B. Instead of using main, maybe we use a feature branch for each feature? Something to think about.

[dmkozh]

To expand on the last point from @sisuresh, I don't think we should remove next for XDR because next is basically a staging environment for the XDR changes. It might contain changes that need to live for longer than a single protocol version. That's especially relevant in the context of faster protocol releases that we aim for - it is possible for a protocol feature to remain in development for longer than a single protocol, and it's very common for protocol features to come with the XDR changes.

For env situation is different and I agree that we don't need next feature for env.