On Thu, Feb 1, 2018 at 4:34 AM, Enrico Olivelli <eolive...@gmail.com> wrote:
> 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. > Yes we need this tool when we enforce EOL. I didn't say we don't need this tool. > > 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 > > > > > >
