Why aren't there RELEASE's cut from CURRENT?

P

pkubaj

Back in 5.x there were test -RELEASE versions cut from CURRENT. They are even listed in http://www.freebsd.org/security/ as early adopter. Why weren't they released during later series (6, 7, 8, 9 and now 10)? It would certainly be something I would welcome, the OS more stable than CURRENT, while retaining most of its features.
 
Similar to snapshots but snapshots are not equivalent.
Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release.
Click to expand...
Snapshots aren't supported for a minimum of six months.
 
How on earth would anyone be capable of supporting a something that is a direct copy of the very experimental CURRENT branch? There are no such promises as feature stability or ABI stability on CURRENT. Terrible idea.

The only support you would get with such releases is the recognition that such things actually exist but no bug/security fixes.
 
FreeBSD 5 was a different animal. There were large changes from FreeBSD 4, and 5 was treated differently than a normal release.

If you want interim "releases", run -STABLE. In my experience, it is at least as reliable as what other operating systems call releases.
 
@@kpa
I was just quoting the FreeBSD website.

@@wblock
I don't think it's a good idea. I used to run 9-STABLE but got back to RELEASE (9.1 now) after experiencing http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072488.html I've tried to solve this problem but it turned out that FreeBSD was sometimes randomly booting OK, but after reboot it hung up. The fact whether it booted or not seemed to be completely random. The same happened after some time to the older kernel.
 
Last edited by a moderator:
You realise that your problem may be specific only to your hardware and the configuration you're using? It can not be inferred from your experience that the STABLE branch is less usable for other people based on one person's experience.

If it was the case that there's something terribly wrong with 9-STABLE you would see lots of reports on the mailing list in a short time. It has happened a few times, there are mistakes made but your case does not look anything like it.
 
I know it may be related to my hardware, nevertheless, the odds of it happening on RELEASE are smaller (at least that's what I hope since it's supposed to be more stable).
 
pkubaj said:
Back in 5.x there were test -RELEASE versions cut from CURRENT. They are even listed in http://www.freebsd.org/security/ as early adopter. Why weren't they released during later series (6, 7, 8, 9 and now 10)? It would certainly be something I would welcome, the OS more stable than CURRENT, while retaining most of its features.
Click to expand...

Releases aren't cut from -CURRENT because it is not necessarily API stable. Doing a -RELEASE means allocated resources to support said -RELEASE, and these are already spread thinly enough.

As above, FreeBSD 5 was a massive change. Those who were using FreeBSD 5 will confirm that there were teething problems.

wblock@ said:
If you want interim "releases", run -STABLE. In my experience, it is at least as reliable as what other operating systems call releases.
Click to expand...

+1 to that. If you're looking for something new-ish but still likely to be reasonably well supported and stable, -STABLE is it.

pkubaj said:
@@wblock
I don't think it's a good idea. I used to run 9-STABLE but got back to RELEASE (9.1 now) after experiencing http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072488.html I've tried to solve this problem but it turned out that FreeBSD was sometimes randomly booting OK, but after reboot it hung up. The fact whether it booted or not seemed to be completely random. The same happened after some time to the older kernel.
Click to expand...

Just upgrading to -CURRENT isn't really a cure-all for random problems. Unlike in the Linux world, you always don't need to update the base distribution to use newer ports.

If your hardware doesn't work with -RELEASE or -STABLE then either your hardware is not supported or you have a hardware problem. Or there is a bug in -RELEASE, which should be reported.

If you have bleeding edge hardware that has support in -CURRENT (but not -STABLE) then it is a roll of the dice for you if you decide to run it. It is not intended for "production" use, and this is why no -RELEASE is cut from it.

If you've had stability problems with -STABLE before, what makes you think they will be less frequent running something from -CURRENT?
 
Last edited by a moderator:
pkubaj said:
I know it may be related to my hardware, nevertheless, the odds of it happening on RELEASE are smaller (at least that's what I hope since it's supposed to be more stable).
Click to expand...

Personally I tend to find -STABLE is actually more stable than -RELEASE. -RELEASE takes so long before it's declared officially released that -STABLE (or -PRERELEASE) as it is then has diverged a lot from when the code was split and includes many extra bug fixes that just don't make it into the release. It can quite often take 2 or 3 months between when the release branch is made and the official release is tagged and very little is backported. One recent example of this was with 9.1. 9.1 has several bugs relating to softupdates journaling. All fixed in 9.1-STABLE. If you keep an eye on the subversion commit logs you see all sorts of stuff that is committed that makes me think why would I want to run -RELEASE and be several months behind?
 
xtaz said:
It can quite often take 2 or 3 months between when the release branch is made and the official release is tagged and very little is backported. One recent example of this was with 9.1. 9.1 has several bugs relating to softupdates journaling. All fixed in 9.1-STABLE. If you keep an eye on the subversion commit logs you see all sorts of stuff that is committed that makes me think why would I want to run -RELEASE and be several months behind?
Click to expand...

I'm not sure if this is policy, but in my view this is why 8.x is still supported.

I tend to stick on the previous -RELEASE train until at least x.1, and usually x.2, unless there is some overbearing NEED to go newer.

All my production gear is still on 8.3 at the moment, and the only reasons for me to upgrade are either security vulnerability or end of life basically. YMMV of course, but in my experience unless there's some funky new feature you NEED in the new release, staying with the "previous" currently supported release tends to work just fine.
 
I track the -RELENG branch on mine. I like the stability.
 
I might be missing something but the upcoming 10.0-RELEASE is "cut from" -CURRENT. At that moment -CURRENT will move to 11.0.
 
As above, ALL -RELEASE versions are cut from -CURRENT at some point :)

I think the core issue is that the OP is wanting something "released" more often.

Long story short: A -RELEASE is made when it is "done" and considered stable. We could be like Linux and just slap a -RELEASE tag on some arbitrary point - if that's what you want, just download a copy of -CURRENT and run everything through sed s/CURRENT/RELEASE/g.
 
throAU said:
I think the core issue is that the OP is wanting something "released" more often.
Click to expand...
To be honest I think they're releasing them quite often enough. New versions are released a lot more often than they used to. I think the plan is currently something like this:
  • 10.0-RELEASE ("cut from" -CURRENT)
  • new 11.0-CURRENT
  • 9.2-RELEASE ("cut from" 9-STABLE)
  • 10.1-RELEASE ("cut from" 10-STABLE)
  • 9.3-RELEASE
  • etc.
 
SirDice said:
I might be missing something but the upcoming 10.0-RELEASE is "cut from" -CURRENT. At that moment -CURRENT will move to 11.0.
Click to expand...

10-STABLE aka stable/10 will be split from 10-CURRENT first, then a RELEASE branch for 10.0 called releng/10.0 will be split from 10-STABLE. The reason 10-STABLE is split before the 10.0-RELEASE branch is that the revision control branch for 10-STABLE can not be split from the RELEASE branch nor does it make sense to split CURRENT twice.

Technically the first release 10.0 won't be that different from 10-CURRENT because it tends to get out the door pretty quickly after the split. It's also the reason why X.0-RELEASEs are not extended releases, they are more like "test releases" and the later releases from the same line are the real thing.

I once used some fancy ASCII art to depict how the branching of the development lines is done:

http://forums.freebsd.org/showpost.php?p=187519&postcount=4
 
Thanks to all, still, I think this entry about early adopters RELEASE should be removed to avoid further confusion.

@kpa, similar ASCII art is in /usr/share/misc/bsd-family-tree, only expanded for other *BSDs.

throAU said:
As above, ALL -RELEASE versions are cut from -CURRENT at some point :)

I think the core issue is that the OP is wanting something "released" more often.

Long story short: A -RELEASE is made when it is "done" and considered stable. We could be like Linux and just slap a -RELEASE tag on some arbitrary point - if that's what you want, just download a copy of -CURRENT and run everything through sed s/CURRENT/RELEASE/g.
Click to expand...

That's another issue - once FreeBSD RELEASE was about every 6-10 months. Now it's more like a year or so (8.4 was released 14 months after 8.3, while 9.1 after almost a full year).
 
Last edited by a moderator:
pkubaj said:
That's another issue - once FreeBSD RELEASE was about every 6-10 months. Now it's more like a year or so (8.4 was released 14 months after 8.3, while 9.1 after almost a full year).
Click to expand...
The releases happen every six months (give or take a month). 8.2-RELEASE, 9.0-RELEASE, 8.3-RELEASE, 9.1-RELEASE, 8.4-RELEASE, all about six months apart.
 
pkubaj said:
I was referring to the time between two releases in one branch.
Click to expand...
I don't think anybody said that. As I understood it there will be a release every six months. Nobody said it had to be from the same major branch.
 
There are no releases of -CURRENT, because it's not ready yet. 10-CURRENT may not even compile from time to time, how are you going to make a release from it?

The -RELEASE means stable and frozen base system (frozen in time -- it's not being updated), from which you can save your base system when Hell breaks loose. The -RELENG branch is the same as the -RELEASE, but it's being updated with security patches.

Then you have two development branches -STABLE and -CURRENT. The -STABLE doesn't mean it won't break (it doesn't bring stability): it just means that the system won't change much. It works OK, but it's being continuously developed, and bugs may creep up in there, so there are no -STABLE releases either. You can think of it as the "CURRENT" branch for the minor version release: FreeBSD 9-STABLE will eventually be tested enough to form a basis for FreeBSD 9.2.

Then you have the -CURRENT. The unstable, the most bleeding edge FreeBSD, that includes work in progress, new features that may not be included in the next release if the prove unstable, experimental changes, etc. It is prone to changes, can easily break, and even not all ports are guaranteed to build on it. It's called 10-CURRENT, because with time it will become FreeBSD 10-RELEASE, but it is in fact a "rolling release" FreeBSD.

So in short:
  1. -RELEASE: stability, tested all round. Once it's out, it doesn't change.
  2. -RELENG: stability + security patches from -STABLE.
  3. -STABLE: think of it as the bleeding edge version of the latest RELENG. Gets updates from -CURRENT.
  4. -CURRENT: the very latest revision of /usr/src.

As such, -CURRENT cannot go out in -RELEASE, since it's neither tested, nor is it stable.

You can see 24.5 Tracking a Development Branch for more information.
 
Realistically, if not for driver support (which, IMHO ideally would be a seperate tree entirely), is there any (other) pressing need to keep making releases so often? i.e., if FreeBSD had a pluggable driver architecture, drivers could be updated outside of a -RELEASE schedule. Sure, new versions of ZFS, new network protocols, etc... but those things aren't "urgent, must have today to make my hardware work!" things.
 
One thing that is lacking is a stable kernel programming API with a stable kernel binary interface that would allow development of drivers outside the source tree. It would also make it easier for hardware vendors to create binary-only drivers that are guaranteed to work on all minor versions of the same major line of FreeBSD with the same driver binary.
 
You must log in or register to reply here.
Back
Top