On Thu, Feb 1, 2018 at 2:51 AM, Ivan Kelly <iv...@apache.org> wrote: > > 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? >
Inclusive. > > > - 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? It means we will NOT consider BC problems with those old releases. > 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. It is case by case. 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. > 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. That is the whole point of having EOL. > > -Ivan >
