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
schedules.

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 perfect.


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.



Regards,

        Chris
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to