>> What do we mean by stopping support for BC? > > It means we will NOT consider BC problems with those old releases.
If EOL means ignoring all BC considerations, then I'm -1 on these proposals. But I don't think we need to go to those extremes. I think we need to specify what BC guarantees we give on any version, and then EOL policies will follow from that. The 3 big BC considerations, as I see it, are: 1) Data on the bookie 2) Client wire protocol 3) Data shared between bookies and clients (i.e. zookeeper metadata) For 1 we can have quite a short timeframe for EOL old software. Bookies can be upgraded individually, and this is controlled by the administrator. For 2 we need a bit longer, because within an organisation there may be many different versions of the client knocking around and it's hard to get everyone to upgrade. For 3 we can pretty much never have a hard break. If a cluster was initialized with an old version, they must be able to able to upgrade that cluster to the latest version of the software. Otherwise they will stick with the old version forever. > for example, the password and digest type was introduced at a very old > release. > There is code assuming ledgers might not have password or digest. However, > the releases onwards would already have those fields. > If we stop supporting those old version, we can remove that special BC > code, which will make code clearer to maintain. This code is in the client. I'm fine with stopping support for all clients older than a certain era. However, yahoo is still on 4.3, so we should at least support back that far until they've been migrated forward. >> The BC >> tests should help in this regard, but we need keep testing scenarios >> where the original cluster was brought up in the oldest version >> (4.1.0). > > If we stop supporting 4.1.0, we don't need to test those scenarios. We > started with from the lowest version we are claiming to support. Are we supporting the software or data that was created with that software? That's two different things. Sure, we're not going to fix bugs on pre-4.4.0 releases, but there are pre-4.4.0 clusters running in the wild (yahoo being an example), and they have to be usable with the latest software, otherwise they will never upgrade. I had this in my previous job where they made a big breaking BC change in the metadata between two versions. While it did allow us to delete a lot of code, we ended up supporting two codebases forever, as customers were unable to upgrade to the latest version. > That is the whole point of having EOL. It's not clear what the point of having EOL is, since we don't have a clearly defined EOL policy nor BC policy. -Ivan
