Exclude releases newer than the host release

[bsdci]

Exclude releases newer than the host release

[skarekrow]

Agreed. We'd need to label them accordingly as well.

Perhaps putting a (UNSUPPORTED -- HOST TOO OLD) or something similar to the EOL stuff I do in fetch is a nice enough reminder.

It's not about diverging, but we need to fetch releases for testing purposes. I'm thinking out loud here what bothers me while implementing.

Fair enough :)

[skarekrow]

Adding to milestone as the python version supports a variant of this.

[skarekrow]

So my input is to do it how I did it in the current implementation. The user may be using his own mirror and gets worried that the RELEASEs he added aren't showing up. He may be just using it as a list with intention of double checking before a host upgrade for instance.

While the message above is useful, if the user types iocage fetch -r RELEASE, we are still going to bail out anyways, so hiding the content on the server is not terribly useful. It also serves as a reminder that FreeBSD has been updated, and the host is out of date, in which case seeing precisely which RELEASEs exist would be a helpful feature for the user.

[gronke]

The user may be using his own mirror and gets worried that the RELEASEs he added aren't showing up.

When the user creates a jail from a custom release, there is no further check on the release version. This is only relevant when starting basejails or creating standalone jails.

He may be just using it as a list with intention of double checking before a host upgrade for instance.

What's the benefit in testing unsupported software that will never make it to production?

It also serves as a reminder that FreeBSD has been updated

It might have a reason to not upgrade a machine. We can print a warning that the host is EOL (looking at #18), but I would rather leave it to the OS itself to notify the user. That's not our business.

--

What if we grey out unsupported and EOL releases with the difference that unsupported releases are sorted to the beginning of the list without a number to select assigned?

[skarekrow]

When the user creates a jail from a custom release, there is no further check on the release version. This is only relevant when starting basejails or creating standalone jails.

That doesn't make sense, we are talking about fetch. Not create or start.

What's the benefit in testing unsupported software that will never make it to production?

Just a contrived scenario, I'm not the user :D They will impress you with use cases

It might have a reason to not upgrade a machine. We can print a warning that the host is EOL (looking at #18), but I would rather leave it to the OS itself to notify the user. That's not our business.

Fair enough, but then they can't fetch a newer release for jail creation. I don't see the point in differing from the current implementation I've done in regards to this.

What if we grey out unsupported and EOL releases with the difference that unsupported releases are sorted to the beginning of the list without a number to select assigned?

How do you suggest we grey things out? If the user isn't using color, that won't translate. It's odd they can't be selectable, but yet are in the list. Once again, I don't see a reason to diverge how I do it in the current implementation.

[gronke]

If the user isn't using color, that won't translate

Agreed. We'd need to label them accordingly as well.

Once again, I don't see a reason to diverge how I do it in the current implementation.

It's not about diverging, but we need to fetch releases for testing purposes. I'm thinking out loud here what bothers me while implementing.

[gronke]

Implemented in 96fd0a5