2018-02-01 13:29 GMT+01:00 Sijie Guo <guosi...@gmail.com>: > 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. >
I agree with Ivan, there can be old clusters with legacy metadata. We should provide some tool to upgrade ZK (meta) data to the latest version. I think that local Bookie data are not a issue as bookie usually automatically upgrades data on first boot with new version (I can be wrong, I am following BK only since 4.3) Enrico > > > > > > -Ivan > > >
