Change to FreeBSD release scheduling and support period

T-Aoki said:
If actually there are no obsoleted-version-specific fixes exists and you are building ports locally, all you need for ports should be reverting the Mk/bsd.ports.mk part of commit to sunset the version. An example here.
Click to expand...
The ports' Makefiles relate to what is in /usr/ports/Mk. All of these contain conditionals that change compilation, prerequisites and whatever dependent on which OS version is used. Obviousely these conditionals have undefined behaviour when the OS version is no longer supported.

Now you say, a server operator who does not want to upgrade every six months, could instead just hack around and patch and redesign these makefiles so that they continue to work. Is this madness or what?

From my experience it is already enough work to fix these makefiles when they happen to be buggy. But not even knowing whether the compilation fails because something is buggy or because it is incompatible with the obsoleted release, that is certainly not practicable in any professional environment.

So what do You really want?

As I said before, operators are forced to upgrade every time whether they want that or not.
 
mer said:
Cool down.
If you update the ports tree, the onus is on YOU to make any modifications needed to actually build the ports.
Point releases are the base system, NOT ports. Skipping a binary upgrade of a point release in the base system does not prevent you from updating ports
Click to expand...
This is what the ports' compilation is dependent upon:

Code: 
/usr/ports # make -V OSVERSION
1303001

This is the specific release, and conditionals in the makefiles branch on it. If that release is EoL, then obviousely the ports maintainers (individuals) will also not maintain the ports' makefiles to continue to behave in a useful way for such EoL release.

mer said:
You are also missing the bigger point.
Click to expand...
No, I just have seen many of these errors in the ports Makefiles, even for supported releases. That's because I do actually build everything from source.
 
PMc said:
… Most often there is no reason at all why one would want to upgrade …
Click to expand...

Ahem.

PMc said:
… Up to now, a new release appeared about once a year. That did mean, upgrade, find the undocumented changes and regressions, spend about three months worrying, testing, fixing whatever - and then have some nine months where the systems would just run, …
Click to expand...

Do you not test pre-release?
 
Cath O'Deray said:
Ahem.
Click to expand...
In earlier times, AS400 were occasionally walled up, and then operated the next ten years without anybody noticing that they depended on them.

Cath O'Deray said:
Do you not test pre-release?
Click to expand...
When the schedule fits, I roll-out prerelease. It usually doesn't make a difference.

Testing is quite pointless: you can only test when you already know where the faults are. When a fault is unexpected, testing cannot normally contain the specific scenario to detect it, because you would then need to test against the product of all options, switches, parameters and inputs, systemwide.
 
PMc said:
… you can only test when you already know where the faults are. …
Click to expand...

That's not the only method of testing.

PMc said:
… Most often there is no reason at all why one would want to upgrade …
Click to expand...

PMc said:
… In earlier times, AS400 were occasionally walled up, and then operated the next ten years without anybody noticing that they depended on them. …
Click to expand...

Photograph from Wikipedia. Occasional walling of such old things doesn't seem relevant to modern day "most often".
 

Attachments

  • 1722684600105.png
    1722684600105.png
    347.6 KB · Views: 22
Cath O'Deray said:
Photograph from Wikipedia. Occasional walling of such old things doesn't seem relevant to modern day "most often".
Click to expand...

I am basically not interested in linking pictures and debating statements as is done on so-called "social" media.

I am operating machines, and the machines need to run, so I view things rather on a factual basis. And so the question is simply, how often since, say, Rel. 11, did some upgrade bring a specific modification that would improve operation?

(With the exception of my laptop which was bought some 2 years ago, and obviosely did gain improvements - some of them because I reported them)
 
PMc said:
I am basically not interested in linking pictures and debating statements as is done on so-called "social" media.
Click to expand...

If you can ignore the picture, then are you also disinterested in debating statements as is done in so-called "forums"?
 
You must log in or register to reply here.
Back
Top