chrcol said:
how you work that one out? 7.3 is not available now so it is not moot.
But, the release is imminent, and if just may be the last 7.x release. Which means, it will get 2 years of support. Thus, 7.3 will be out, and supported, longer than 7.1.
is fine I guess if you know what path to enter to the archive directory, I do not.
Fire up a web browser or FTP client, go to
ftp://ftp-archive.freebsd.org and click around the directories until you find the install directory. Voila! You have the path to use.
exactly that, 6 months is next to nothing. Why not 18 months for every minor version instead of every two?
Considering that, for example, OpenBSD releases new releases of the OS every 6 months, and only supports the current + last release, you'd think having 18 months for a minor release would seem like an aeon.
This fast paced release schedule of freebsd also serves to reduce 3rd party support as other vendors cannot keep up (poor from them I know but its how it is).
And that's the point of keeping API/ABI compatibility within a major version, so that a 3rd-party dev can develop a program for 7.0 and have it still work on 7.3, which gives close to 5 years of support. Or create an app for 6.0 and have it still work on 6.4. Or create an app for 8.0 and have it still work on 8.whatever.
Then, you add in the compat6x, compat7x, compat8x, etc ports, and you can run a binary app for many, many, many, many years. How long ago was 5.0 released? The last port that required compat5x was just recently removed from the ports tree. And yet, you could still run that app on a 7.2 system.
Just because a new minor release is made available does not mean you are forced to instantly jump up, run out, and upgrade to it.
Maybe I am alone on this but I would like to see .0 .1 at the very least be testing releases with .2 been the first STABLE release, and then each major version to have garuantueed 6 minor releases (2 testing + 4 stable).
Does that mean you are volunteering to setup the QA framework for that, and to devote the extra man-hours/hardware resources to support that many simultaneous releases, for creating binary packages, for testing changes, etc?
That way us people running servers can be reasonably confident by the time the first major release is out .2 it will be through some more thorough testing.
And how is that any different from just waiting for X.2 to be released, and not migrating between major versions until then? For example, I have several 6.3 servers running in production, waiting for 7.3 to be released before I start to migrate them across. And don't have any plans to migrate them to 8.x for at least another year.
I also would like to see alot more stuff backported as well,
You mean MFC'd (merge from current) or MFS (merge from stable). Just check the commit logs in the SVN repo, you'll see that this happens a lot. HOWEVER, an MFC/MFS *MUST NOT* change the ABI of a major version without a *VERY* good reason. IOW, you won't be seeing the new USB stack MFS'd to 7.x, you won't see the VIMAGE stuff MFS'd to 7.x, you won't see any major library changes in the base OS, and so on.
I think there has been a deliberate decision made at some point to only backport critical fixes as to encourage people onto the latest and greatest version.
Considering the number of changes between a 7.0 system and a 7.3 system, I would have to say you are very much mistaken. Same for the changes between a 6.0 system and a 6.4 system.
You have to step back and look at how hard the FreeBSD devs try to maintain a stable ABI within a major branch
in support of 3rd party development, and how hard they try to balance that with getting new features into the system. Once you do, you'll realise that there really is a method to the seeming madness of supporting 6.x, 7.x, 8.x releases all at once, with development going like mad in 9-CURRENT.
