challenge: end of life for 6.2 is premature with buggy 6.3
cmarlatt at rxsec.com
Thu Jun 5 16:46:43 UTC 2008
Ivan Voras wrote:
> Chris Marlatt wrote:
>> The option provided seems like a fairly good compromise to both
>> interests. Pick 6.3 (or anything the release team wishes) to support for
>> a longer period of time. Keep all other releases to 12 month support and
>> continue doing what I believe is some fairly incredible work. I really
>> don't see the downside to it. If anything it should reduce the work load
>> for the team and let them focus on making considerable progress.
>> Especially considering Ken Smith's recent post regarding future release
> This is already being done: 6.1 was a "long term support" release.
> The topic comes about pretty often. I think it's because people are
> still impressed / spoiled by 4.x and wish they had a stable operating
> system that's supported for 6+ years (like 4.x had been). I even heard
Spoiled is probably a good word for it. But you have to admit it's
extremely useful to the user base to have such support. This was quite
evident by the apposition to discontinue the 4.x branch.
> commercial / embedded companies saying they would use FreeBSD if only
> they had a 5+ years run off a branch (which is comparable to what Debian
> has, if you allow 3.0 and 3.1 to be "similar enough").
> But all is not so bad: consider for example 7.x: 7.0 was released
> 2008/02, and from Ken's schedule the last release, 7.4 will be released
> 2009/12, with probable support for maybe 1-2 more years which makes the
> whole 7.x generation of the OS officialy supported for 3, maybe 4 years,
> which is a lot in fast technology-changing world.
I think you're missing the point. Whereas it is indeed helpful to have
the major release supported for that duration of time. The concern was
over the minor release support. For instance if 7.0 is only supported
for 12 months it doesn't really matter if 7.x is support for 48. You
still need to upgrade and deal with any potential problems 7.1 or 7.2
induces if you wish to continue having "vendor supplied" security fixes.
However using the 7.x tree as an example is problem not the best. 7.x,
at least from what I've perceived, is a fairly active development
branch. The 6.2 to 6.3 change is somewhat a better example but still not
> I know long term support is not doable with the resources the project
> currently has, but I've been toying with the idea that maybe there's an
> opportunity for commercial development here - a company that would
> backport security fixes and important driver fixes for ($$$ *
> (N-YEAR_OF_LAST_RELEASE)) more years or something.
More information about the freebsd-stable