[Releasing] Deprecation - we are doing that wrong

[Jędrzej Nowacki]

On Thursday 04 of February 2016 15:17:03 Thiago Macieira wrote:
> On quinta-feira, 4 de fevereiro de 2016 11:43:12 PST Robin Burchell wrote:
> > Hi,
> > 
> > Well written mail :)
> 
> Hello all
> 
> Agreed, thanks for bringing this up.
> 
> > On Thu, Feb 4, 2016, at 09:15 AM, Jędrzej Nowacki wrote:
> > >  From time to time we are deprecating/removing a module. Great it is
> > >  normal
> > > 
> > > that certain technologies fade out. We announce that the module is
> > > deprecated and removed, then people start complaining, it is also
> > > normal.
> > > Nobody want to upgrade software because it is costly. Then we get scared
> > > and we say, "ah don't worry it is deprecated, but we will keep it
> > > working
> > > for a while and we will still ship packages with it...". That in my
> > > opinion is not normal.
> > 
> > Agreed. If a spade is a spade, call it a spade. If nobody is working on
> > it, and nobody will be working on it for valid reasons (whether
> > technical like QtQuick1, or business in the case of QtWebkit where AIUI
> > there simply aren't enough resources to dedicate the required effort to
> > it), then it's deprecated, whether or not that's a popular announcement
> > to make.
> 
> I'd like to make a distinction here between deprecated and removed. We have
> five states, which I described more in detail in some blog back in 2011 or
> 2012, which you can find for more info:
> 	1. Active
> 	2. Maintained
> 	3. Done
> 	4. Deprecated
> 	5. Removed
> 
> Deprecated means "don't write new code using this, begin porting away from
> it as it will be removed in the future", whereas "removed" means "breaks
> unless you port away". Now, we can have variances of deprecated, which I
> will not go into.
> 
> Specifically for modules, we promised this:
> 	qtwebkit		Deprecated
> 	qtscript		Deprecated
> 	qtquick1	Removed
> 
> We also tried to say that Deprecated modules would work with new releases,
> but we clearly failed to do that because of our extensive use of private
> APIs across modules, in which I include our entire buildsystem starting at
> load(qt_build_config).
> 
> > >  I see a few options:
> > > A. we ask someone to maintain a deprecated / removed module, but then I
> > > guess it would be better to change the status to Done.
> > 
> > I don't think this is in practice an option, because in reality this is
> > little more than life support. It basically means "we'll keep the lights
> > on and fix compilation/test failures but nothing else" which in turn
> > leads to the reputation hit that I already mentioned.
> 
> Agreed, this is not feasible. Whether we would call this "Done" or whether
> it's a sublevel like "Deprecated with Support", is a discussion for another
> day.
> 
> Skipping B because I agree with Robin's arguments.
> 
> > > C. we can disable tests completely for such modules. So we would assume
> > > that if they compile then they are good enough. You know what are the
> > > consequences of it.
> > 
> > Yes, but it also reflects reality: it's deprecated. There's nobody
> > working on it. If nobody is working on it, there should be no real
> > change going on in the module itself, and the deprecation has already
> > indicated that we don't want to spend resources on testing and
> > maintaining it. So this sounds better, since it allows trivial fixes
> > without blocking either those fixes or releasing efforts.
> 
> I think this level should be applied to the modules in Deprecated state. The
> minimum we need is the ability to say "it compiles".
> 
> > It does have the obvious downside of potential breakage. Perhaps staging
> > should be restricted to either someone who wants to volunteer to
> > undertake that for that module (or maintainers, collectively), who would
> > be responsible for vetting changes to make sure they _are_ really just
> > simple compilation fix-type things.
> 
> Agreed on the procedure.
> 
> We should also be very aware of the fact that disabling tests completely
> means we could introduce breakages we won't find until a user hits it. I
> would counter-argue by saying that most such issues won't be caused by
> changes in the deprecated module, but by those in other module on which it
> depends. That means a failure of testing and a regular bug report.
> 
> It also means a willingness to investigate whether the regression reported
> against a deprecated module was caused by changes in other modules.
> 
> > > D. we can avoid shipping them completely
> > 
> > Honestly, I'd prefer this. Deprecated (to me) means zero effort
> > expended, but I guess there was already a decision taken to reverse this
> > for reasons I'm too lazy to go find out right now. I guess a combination
> > of C & D could also be an option: don't ship them, and disable testing
> > to enable easy fixes from whoever wants to volunteer to go make them.
> 
> I wouldn't prefer this. This is only possible for Removed modules (by
> definition, actually).
> 
> Trying to make Deprecated = Removed will simply anger our users, especially
> those of qtwebkit, and make fools of us because we've been promising to keep
> compatibility. We may as well call the next release after that 6.0.
> 
> So I would say we *have* to bite the bullet and at the very least keep those
> modules compiling. It adds work, but it's work we have to do. We only need
> to find a way to do that work without introducing burden at the wrong
> times.

Yes, I realized after sending, that mixing in one email deprecated and 
removed, is not a good idea... Anyway it seems that we agreed on this support 
level from the CI point of view:

        1. Active -> Built encouraged, testing encouraged 
        2. Maintained -> built and tested
        3. Done -> built and tested
        4. Deprecated -> built 
        5. Removed -> built

Thanks!
  Jędrek