suggest removing -d requirement to upgrade to new releases

The way the upgrade process currently works is to examine the meta-release file for the 'Supported' field. In the event that the Supported is set to 0 then everyone is prompted to upgrade. We don't set it to Supported yet deliberately so that we can get these enthusiasts to test the upgrade process for us. Subsequently, while the definition of the '-d' switch is incorrect for a short period of time I think its best that the '-d' switch is scary as setting the meta-release file's 'Supported' filed is an indication that we think it is safe to upgrade for everyone.

I do think the release notes could be better about explaining why the '-d' switch needs to be used for a short period of time after release though.

On Wed, Apr 29, 2020 at 10:37:17PM -0000, Brian Murray wrote:
> the upgrade process for us. Subsequently, while the definition of the
> '-d' switch is incorrect for a short period of time I think its best
> that the '-d' switch is scary as setting the meta-release file's
> 'Supported' filed is an indication that we think it is safe to upgrade
> for everyone.

There's different risk levels for different people. I understand the
people who want to upgrade to the new LTS during release week but who want
to make sure they aren't accidentally jumping onto the -devel release.

> I do think the release notes could be better about explaining why the
> '-d' switch needs to be used for a short period of time after release
> though.

Please do give some curl | awk command that would let people know if
do-release-upgrade -d will move them to the newest release or if it
will move them to the devel release.

I still think we'd be better served by -d meaning devel and nothing else,
and lettinng people who know enough to run the command upgrade without
the fear of upgrading too far.

Thanks

I agree with the idea that the machinery should offer a new release only when we really consider it stable, which we define as having a point release. In other words, if a user does nothing and they're on 18.04, they don't get nagged to upgrade until 20.04.1.

On the other hand, I think that when a user *requests* a release, either through `do-release-upgrade` or through the GUI, it would make a lot more sense to provide the most recent *available* release for the track (normal v. lts) they're on. In other words, if they're on 18.04 or 19.10 and they look for a new release, they should get 20.04, even if 20.04.1 isn't out yet. To do anything different is like saying there's no new release and with all the news saying the new release is out, this is really confusing and makes for a lot of annoying support requests.

Going back to my original note, I think that for folks on the normal track, they should get nagged to upgrade before the point release. They're already not looking for LTS capability, so why should we try to provide it?

Just to interject, people rightfully believe do-release-upgrade (without -d) will upgrade them to Focal, because that's what the Release Notes say.

https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#Upgrading_from_Ubuntu_18.04_LTS_or_19.10

IMHO, It's either released or it's not. I like @wxl comment of waiting to prompt but allowing upgrades.

The release notes have been fixed to document the need for -d until the point release.

I categorically disagree that we should message an LTS-to-LTS upgrade, prior to the first point release, as anything other than "development". During each LTS cycle, we are routinely fixing critical upgrade bugs up until the point release, and no one who is not prepared to deal with those on the same level as a user installing or upgrading to a beta release of Ubuntu should be doing that LTS upgrade at that time.

> Going back to my original note, I think that for folks on the normal track,
> they should get nagged to upgrade before the point release. They're already
> not looking for LTS capability, so why should we try to provide it?

That is already the case. This bug only affects LTS-to-LTS upgrades.

I'm closing this bug as Opinion, as I don't see that there is any clear path to addressing the request while satisfying the constraint that we don't want casual users who are not prepared to deal with critical upgrade bugs without overwhelming our support capacity to be doing LTS-LTS upgrades before .1.

As a user and developer, I just hit this situation and expected -d to mean devel because that's what the manpage of do-release-upgrade says.

It would be ideal to:
* Not nag the 18.04 users to update to 20.04 until 20.04.1 release is out (this is the current behavior)
* Allow users on 18.04 (or other) to do-release-upgrade without '-d' to get to 20.04 at any point from the time 20.04 is released.

Are these two behaviors are coupled?

If there will be a period of 3 months between 20.04 and 20.04.1 where this -d flag is needed for a non-development release and that is not going to change, then perhaps the manpage should be updated with a caveat.