[Releasing] Deprecation - we are doing that wrong
Oswald Buddenhagen
oswald.buddenhagen at theqtcompany.com
Thu Feb 4 14:29:18 CET 2016
On Thu, Feb 04, 2016 at 01:30:46PM +0100, Knoll Lars wrote:
> On 04/02/16 13:25, "Releasing on behalf of Oswald Buddenhagen" <releasing-bounces at qt-project.org on behalf of oswald.buddenhagen at theqtcompany.com> wrote:
> >so any reasonable calculation of pay-off assumes these modules'
> >presence until qt6.
>
> The question is about where they are present. They can’t be part of
> what we support in the future, we have already agreed on that.
> Consequently they are not part of what we release.
>
we established previously that keeping them in minimal form in the
releases is the overall cheapest way.
it also happens to be the most user-friendly way. win-win.
> >> Like that we decouple the problems and can work on getting some source
> >> packages for these unsupported modules with a different time schedule.
> >>
> >why do you think that we'll *ever* have more time for that than right
> >now? especially given that it will be *more* total effort if we take it
> >out of the general process?
> >
> >and that doesn't even consider the user perspective on these pseudo
> >releases ...
>
> They are and should not be part of our release. They aren’t officially
> supported, and making them compile and offering a source tarball is
> merely a convenient service we can offer.
>
this borders on mocking our "legacy" users.
> The cost of them blocking our releases is what bothers me. That one is
> what’s expensive, not making them compile in an independent effort.
>
i don't see how this sort of tactical thinking makes any sense. what
does it matter even if the release is delayed by a day by that?
and we've alrady spent more time discussing the matter than it would
have taken simon to implement the autotest suppression logic that would
solve the entire issue (for now).
More information about the Releasing
mailing list