Release date for qube os 4

[grv]

I see on https://www.qubes-os.org/doc/releases/4.0/schedule/ that Dec 11 is the last date mentioned to decide if rc3 is final. Have we taken the decision?

If I install rc3, would I be able to update to QubeOS 4 in place (without having to migrate my VMs manually) ?

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-12-12 17:33, grv wrote:
> I see on https://www.qubes-os.org/doc/releases/4.0/schedule/ that
> Dec 11 is the last date mentioned to decide if rc3 is final. Have
> we taken the decision?
>

As far as I know, the decision has not yet been made. Either way, the
schedule will be updated soon.

> If I install rc3, would I be able to update to QubeOS 4 in place
> (without having to migrate my VMs manually) ?
>

We'll announce this as soon as we can. We usually can't say
for certain whether an in-place upgrade will be possible until very
close to the stable release.

If we say that it'll be possible based on our current plans, and those
plans change, users may be inconvenienced (or worse). If we refrain
from changing our plans because we've already said that an in-place
upgrade will be possible, that limits our ability to improve the final
release while it's still in testing. We don't want to make promises
that we can't keep, but we also don't want to lock ourselves into a
path that turns out to be sub-optimal. That's why we wait to announce
things like this until we can be reasonably certain.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJaMIrWAAoJENtN07w5UDAwFb0P/jXEX9uR9gRG4epXtm0MD6Nb
VRfFclrqa/stuPlRkqnI3Ny/l8nDzltw3SX3RH9Ju9c2mK78XVKBGabw9VQbnLCP
lqKAVn2rcEZsMorKhUjjuwIsQjE6WJ9/OwrofTGjBLGlURNy2MvtChxe70u1XMw8
PlTrmA4JgS3lBLLP7LLNi71WyQ2HZNZaI/k9yJ1v7LdCwyikVyhBnh3P3dc/YlZi
I9i4k/h2W8rDcBuTG3/S+MntMkAMypGpdqDwWEQCtR+JSsV1x5qT8gc6/WVPOhVs
A1I7qBLT2F5GjZg5ZUCTKdXIOu1FVM1pYsuYuTrLx5XbVvXVCWWEjC/DqQLEul77
zUzZQDqkm/NfV7L8i3/CP1rlzG8PKPpzV4bM0ERsP5vrmOybyeKIu6rwoJzPPnLB
8Ci2VOKG/I3/Ywf29GIl4uDydyBd5jHJYK5vxllGdNPwiBsQGPkRe4CSdp7QG2eO
o1ukxocmNSdKHgzs98ry1AvDPrbVKo62zRc+Q11W6B7/P0f4u5qIK5cVnVhk6jb2
N/tgx2y4wMRJb2u3fF0t/YRci3qtA9GyaC1mxF9UOCYY+lalOxrT/tyhgd8p6mgu
6f6X6pjgli+kbwCOszy1N1t5xrHyUY/KmDvEb4HkyrLu2Ut1y8IM+mS4nk0NygvR
temARax0ky3Duiw/Cg3C
=fZMg
-----END PGP SIGNATURE-----

[Jon Solworth]

On Tuesday, December 12, 2017 at 9:05:30 PM UTC-5, Andrew David Wong wrote:

> We'll announce this as soon as we can. We usually can't say
> for certain whether an in-place upgrade will be possible until very
> close to the stable release.

Andrew, now that the schedule for 4.0rc4 is out, it would be good to know what work remains to be done before 4.0 can be replaced. I would (and I'm sure the community would) appreciate a few words on this.

thanks,
Jon

[Tom Zander]

There is a wealth of information on the github pages. For instance the
‘milestone’ for the 4.0 release still has a large number of open bugs.

https://github.com/QubesOS/qubes-issues/milestone/17

Speaking from experience, the devs may bump the less important ones to the
next release, so don’t see that as “written in stone”.

Also hae to make clear that I see very little communication from the core
devs, so I have no idea about their thinking here. My thinking is that since
the milestone is there, it likely is important to someone :)
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/floweethehub

[Yuraeitha]

Hey Andrew,
Is there any chance if we can get recommendations, as for when it is recommendable to re-install between the Qubes release candidates? I.e. an extra line in the release schedule saying re-install recommended, or something akin to that? I'm just pondering thoughts here, whether it's possible or not.

From what I can gather, release candidates can be seen in two ways.

- 'Updates are so major, that a re-install for the next release candidate makes for a more stable and reliable system.'

or

- 'Some systems won't work properly before updates are applied, therefore creating an impossible circle if booting, installing, reaching the update process, is unreachable.'

When decisions are made in keeping or making a new release candidate, it would be greatly appreciated to have a means to know if re-install is the former, or the latter, scenario, or maybe even sometimes both. This would save a lot of time for many people to re-install, or even be worried and stressed about not doing so, when not knowing if one should or not.

Is it possible we can include this tiny detail somewhere, i.e. in the release schedule, or somewhere else that is a sensible location that is easy to find for users?

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-12-15 19:14, Yuraeitha wrote:
> On Wednesday, December 13, 2017 at 2:05:30 AM UTC, Andrew David

> Wong wrote: On 2017-12-12 17:33, grv wrote:
>>>> I see on https://www.qubes-os.org/doc/releases/4.0/schedule/
>>>> that Dec 11 is the last date mentioned to decide if rc3 is
>>>> final. Have we taken the decision?
>>>>
>
> As far as I know, the decision has not yet been made. Either way,
> the schedule will be updated soon.
>
>>>> If I install rc3, would I be able to update to QubeOS 4 in
>>>> place (without having to migrate my VMs manually) ?
>>>>
>
> We'll announce this as soon as we can. We usually can't say for
> certain whether an in-place upgrade will be possible until very
> close to the stable release.
>
> If we say that it'll be possible based on our current plans, and
> those plans change, users may be inconvenienced (or worse). If we
> refrain from changing our plans because we've already said that an
> in-place upgrade will be possible, that limits our ability to
> improve the final release while it's still in testing. We don't
> want to make promises that we can't keep, but we also don't want
> to lock ourselves into a path that turns out to be sub-optimal.
> That's why we wait to announce things like this until we can be
> reasonably certain.
>
>

> Hey Andrew, Is there any chance if we can get recommendations, as
> for when it is recommendable to re-install between the Qubes
> release candidates? I.e. an extra line in the release schedule
> saying re-install recommended, or something akin to that? I'm just
> pondering thoughts here, whether it's possible or not.
>
>> From what I can gather, release candidates can be seen in two
>> ways.
>
> - 'Updates are so major, that a re-install for the next release
> candidate makes for a more stable and reliable system.'
>
> or
>
> - 'Some systems won't work properly before updates are applied,
> therefore creating an impossible circle if booting, installing,
> reaching the update process, is unreachable.'
>
> When decisions are made in keeping or making a new release
> candidate, it would be greatly appreciated to have a means to know
> if re-install is the former, or the latter, scenario, or maybe
> even sometimes both. This would save a lot of time for many people
> to re-install, or even be worried and stressed about not doing so,
> when not knowing if one should or not.
>
> Is it possible we can include this tiny detail somewhere, i.e. in
> the release schedule, or somewhere else that is a sensible
> location that is easy to find for users?
>

We've actually already started doing that. :)

Take a look at our last two release candidate announcements:

"As a consequence of the partition layout change, it will be necessary
for current 4.0-rc1 testers to perform a clean reinstall of 4.0-rc2
rather than attempting to upgrade in-place."

https://www.qubes-os.org/news/2017/10/23/qubes-40-rc2/

"Current users of Qubes 4.0-rc2 can upgrade in-place by downloading
the latest updates from the testing repositories in both dom0 and
TemplateVMs."

https://www.qubes-os.org/news/2017/11/27/qubes-40-rc3/

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJaNK9ZAAoJENtN07w5UDAw0+oQAMQ8EFQNpMnRIe/yhC1o4v9G
PKta+7YsCjfawTu7oWUdbh8ETKAzqo7BGyqZeZsQzOIlgRLZo4/1C3BCLSsYjUQm
E8kYADe/8i4YGyeXU2SUeGgzSrbZGfvWdE2dMB5oc3uLp0eYB/jtKMIxNdbPRp6B
vmDvTFRgSoUNHq8hgS+p8A8VNB696xPoCx4jzWHjo7NbWubaRGRKsArCHkPjwfMW
x5Skro/DslYjSU+Bx5r61sJLZZT46bFIrqogc5pmZzcvw3M0VnjKZD2H0D5RoOrD
JKuz+2RiZZRkqzNZpS5fOxD392Y0r9D3YlcEM/1+QrMy1xfix8wdik4bDb/49Rxu
+ZgI5yZw2HpDILc2wUcF2Ph+LvS7u8J1VwwkZXdgyjL4CO2DZBO0VMiiUvDwg98Q
8WuWZDPfkgFE8fsNiStiQwFtqOE/hCvAhJ6qE4pJMujMdbm1mjQJErQH1LCAE9pV
cz2fLHWlPzWp06PqNV9zRFHA4twQUat0IDTd2wikPDG30HzjcE+WVengoKo8iTCs
/EvbfmY6MabDMkisC+y7zgQkZeGIGFTdjvG1SG6asYdklrNvGHfJkOlQw376Fkda
a0+aC3A2qy8pgbh6vC8voTkpuzd7+H/gXET2kyzGdzA9tWKhpqXHtP0RWUpQ7EXC
1gzCPMVIykmTkIUsK3TL
=VA2a
-----END PGP SIGNATURE-----

[Yuraeitha]

Thanks Andrew, this is pretty awesome. It really takes off the pressure to figure out whether to re-install or not. I can only speak for my self, but I'm very grateful for this little piece of information, it removes a lot of worries, especially, and in particular when on busy schedules. Thanks for the link and quotes too, it gives a good and helpful idea as for what to look for in the future releases.