Figure out how the heck to version all of this

[relrod]

22:47:37 < relrod> I need to figure out the versioning thing. When everything was in one repo, I tagged each flight. Now that things are split into several repos, that's going to be annoying. And anyone else that uses mapview doesn't care about our flights anyway (presumably) so the tag is pointless for them.
22:48:04 < relrod> So I think only mapview-noexc should get tags, but then if we do that, we should be able to tell exactly what commit it depends on for mapview and mapview-websocket and such
22:48:35 < relrod> which makes me think that they should get releases before each flight, but why should library versions correspond to when we do flights?

We should figure this stuff out.

[relrod]

I think the order of operations here is something like this:

• Release mapview-3 to hackage (soon/whenever)
• Release mapview-websocket-1 to hackage (soon/whenever)
• Figure out what to do about mapview-noexc

Regarding mapview-noexc

Here are some options we have:

• Tag mapview-noexc after every flight. So we work on master there, branch to nbpN-pre to soft-freeze a few days before flight as normal, then after the launch, tag the HEAD of nbpN-pre as nbp-N and delete the nbpN-pre branch. The disadvantage here is that you can't install mapview-noexc and be able to process data from 3 flights ago, you have to install the tag specific to that flight.
• Make mapview-noexc actually a super-repo that contains multiple cabal packages such as mapview-noexc-nbp3 and mapview-noexc-nbp4. These would not be mutually exclusive packages and we'd be able to fine-grain the versions of mapview and mapview-websocket (and so on) as needed.
• (other ideas go here)

Here is a non-option:

• Keep doing what we are doing right now. Right now, if mapview-websocket has a breaking change, mapview-noexc will fail to build because the modules that pertain to the old flights won't be able to build. This won't scale.