I just thought I'd share how I think future release versions will look in the future. One of the problems users face is understanding the matrix of compatibility among various versions. While we've tried to keep things backward compatible within a minor release (i.e. the y in x.y.z) that doesn't mean that features and incompatible bug fixes haven't crept in there along the way which means that a 3.4.8 client might end up being compatible with a 3.4.5 server but only if you avoid a particular feature or use a feature a certain way. While we document those things pretty well in upgrade docs, it's easy to forget over time just what works with what.
Going forward, I think we want to keep things simple by being able to tell users that while it is best to match the version of the client with the version of the server, any patch release (i.e. the z in x.y.z) of a client will work with any version of that line on the server. So as long as you match the y in x.y.z you should be fine. Accomplishing this on our end will take some diligence but if we do it right it should make things easier for our users. It will also mean that we will likely pick up cadence along the minor releases which will be more feature heavy. We won't likely keep long maintenance cycles on minor releases with deep patch counts (like the upcoming 3.4.12). Finally, in taking this approach, I think it is ok for the language variants to lag behind Java within a minor version. We allowed this in the past and for 3.5.0 (e.g. g.tx()). I think however that we need to be diligent/expedient in catching up all lagged features within patches before we stop a patch cycle. In other words, we should only be content to stop support on a minor line once all the languages hold the same functionality. I imagine we might have some rule breaks for that here and there (e.g. graphbinary is still not supported in JS), but we can make those decisions on a case by case basis.
