Hi,

> Personally, I'd prefer to start consolidating MATE 1.16 now and I would love
> to see it long term supported by upstream.

I'm afraid we won't be able to add LTS support... our team is too small for 
that.
I'll try to submit patches for most important bugs (for example, I have a list 
for
Ubuntu 16.04 already), but there's only so much I can do.

> I know that some MATE packages will face some major changes for 1.18
> (e.g. Caja being ported to GtkApplication class). For Debian stretch, would 
> it be
> an option (asking upstream here) to only include some MATE packages from
> 1.18 and leave the rest at 1.16?

Well, we decided to migrate our remaining packages to GTK+3 for 1.18. This will
not impact Debian much since you already provide GTK+3 builds, but for some
other distros, which will migrate from GTK+2 build, we need to make sure there
won't be a mix of toolkits (it won't work). So, most probably the next dev 
release
(1.17) will have GTK+3 only code - and packages that depend on other packages
will require version 1.17 of them for building.

> Or another approach, would it make sense to have 1.16 micro releases with 
> bigger
> patchsets than usual?

I don't think we'll make big changes for 1.16.x releases - they're meant for 
bugfixes,
and people don't expect regressions from these... I mean that large changes are 
more
likely to introduce regressions. Of course we test our changes before 
releasing, but
some bugs might slip in.

So my suggestion is still to aim for 1.18 for Stretch.

What do other MATE maintainers think about it BTW?

Reply via email to