[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-devel
Subject:    Re: [qubes-devel] guest OS support matrix
From:       Patrick Schleizer <patrick-mailinglists () whonix ! org>
Date:       2016-01-14 3:02:09
Message-ID: 56970FB1.1070001 () whonix ! org
[Download RAW message or body]

Marek Marczykowski-Górecki:
> On Wed, Jan 13, 2016 at 10:06:10AM +0000, Zrubi wrote:
> > Hi,
> 
> > Do we have any official statement about the supported guest OS versions?
> 
> Actually we don't have even official statement about which Qubes
> versions are supported...
> We should work on it, thanks for bringing it up!
> 
> > Where supported means you (ITL/Qubes developers) provide qubes related
> > packages for a specific Qubes release.
> 
> > I mainly interested about fedora releases - but the same info would be
> > helpful about other distributions as well for sure.
> 
> I think the answer here is (in practice):
> R2: fc21 (which is no longer supported by Fedora)
> R3.0: fc21, (fc22), fc23
> R3.1: fc21, (fc22), fc23
> 
> And for Debian it would be:
> R3.0: (wheezy) jessie
> R3.1: (wheezy) jessie (stretch)
> 
> In parentheses I've put versions for which we publish the packages, but
> don't do excessive testing.

That table would be useful in the documentation.

Yes, best to not support that many with excessive testing. For example
on Debian, just jessie. And moving on to stretch once that gets close to
the new stable.

> > And because we have more than one supported Qubes versions and more
> > than one guest OS distributions/versions we should have create a
> > compatibility/support matrix.
> 
> > Right now the docs only talking about ITL supported vs Community
> > supported templates - but not about OS versions.
> 
> I think we should have some clear policy on that. For both supporting a
> Qubes versions and VM templates. Some proposition:
> We support (release updates with bug fixes) for the most recent Qubes
> stable version and for the previous stable version up until a year after
> releasing the current one.
> This would mean:
> R3.0: supported, not end date set yet (will be a year after releasing
> R3.1)
> R2: supported until Oct 1 2016 - a year after releasing R3.0
> 
> Generally IMO we should encourage users to upgrade to newest available
> version, so maybe even harder policy, like:
> - full support up to 6 months after releasing the next stable release
> - security fixes only, within next 6 months
> 
> What do you all think about it?

Go short. I am amazed how productive you are, but loading too much
maintenance work on you for old versions is not great. You know best how
much effort it generates. Go shorter. Long time support versions are
enterprise features. So interested enterprises should pay for this. As a
user of a security focused distribution, I am more interested in latest
security rather than old versions. Ultimately up to the Qubes Council.

Cheers,
Patrick

-- 
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/56970FB1.1070001%40whonix.org. For more \
options, visit https://groups.google.com/d/optout.


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic