> We have switched to Time Based Release Schedule > <https://cwiki.apache.org/confluence/display/BOOKKEEPER/BP-13+-+Time+Based+Release+Plan> > since > 4.6.0 and we have 3 successful releases since then - 4.5.1, 4.6.0 and > 4.6.1. And the 4.7.0 release is coming in a month or so. According to > BP-13, we need to enforce an EOL policy for our releases: keep the releases > in one year and mark the releases older than one year as EOL, no BC would > be considered with those versions. Perhaps we should define an EOL policy before EOLing releases. As part of this, we should define what we support for BC and what we don't. For example, do we support BC on all ledger managers? Just hierarchical and flat?
> I would like to propose we start enforcing EOL at 4.7.0 release: +1 > - we only keep all the releases higher than 4.4.0 (4.4.0 was released about > one year and half ago). inclusive or exclusive of 4.4.0? > - stop supporting BC with releases smaller than 4.4.0. This includes: move > the documentation of those releases as archived, remove them from BC tests, > delete the legacy code that was there for supporting BC with these releases. What do we mean by stopping support for BC? We haven't broken client compatibility since 4.1.0. I don't think we have any special code for handling it. But I think there is special code for handling old ledger metadata formats (which haven't been upgrades). If someone started their cluster on version 4.1.0, and upgraded version by version to 4.6, then the ledger metadata from 4.1.0 will still be there, and their 4.6.0 client will be depending on the legacy code paths to function. I don't think it's as simple as just removing the legacy code, and it's something we need to be very careful about. 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). -Ivan
