Upcoming Releases Schedule...

[Ben Kaduk]

On Sat, Sep 20, 2008 at 9:52 PM, Aristedes Maniatis <ari at ish.com.au> wrote:
>
> On 21/09/2008, at 10:34 AM, netgeek wrote:
>
>> Perhaps there is a middle ground here?  What about a statement that each
>> major branch (6.x, 7.x) will be supported for at least 24+ months from its
>> last production release?  Smaller periods of support could be given to minor
>> releases along the way (7.2, for example), but at least companies would know
>> that if they installed a 6.x version, they'd have support for a couple of
>> years, even if that might mean upgrading to a newer minor version if there
>> was a problem.
>
> This is already the case [1]. From each major branch one or more releases
> are designated as 'extended' and supported for 24 months. All you have to do
> is pick one of those and you've got support for 24 months. For example 6.3
> has extended support in this way.
>
> RELENG_6 itself will be supported 24 months after the last release. Given
> roughly 18 months between major releases and about 12 months of ongoing
> releases from the previous branch after that, 4.5 years is roughly how long
> each major branch is supported for. That is already clear as could be. I
> can't quite understand what Jo Rhett is offering to the community that he is
> upset isn't being taken up. I think he wants some other arbitrary point
> release to be given extended support, either because in his case 24 months
> is not enough, or because he wants every release to have 24 months of
> support, or something else, I'm not sure.

I think mostly, he just wants to know in advance which releases will
have 24 months of support.
Also, it would be very nice if those releases overlapped, so that
one can jump from one long-tem-support release to the next.

>
> Jo, you say that he have had to maintain your own patched build of old
> FreeBSD releases because you need to keep them in production for longer than
> EoL period. Can I suggest that the first step is for you to publish those
> patches somewhere public and allow others to have access to them. Then

I'll second that.


-Ben Kaduk


> you'll have a chance of convincing others to contribute to your patch sets
> and eventually of convincing FreeBSD to officially sanction them. Go and
> create a new sourceforge project or convince your boss to set aside some
> space on his web site/svn server/etc for this project. Tell him that if it
> goes well, you'll be creating a whole lot of good will for the company in
> addition to the prospect of getting other people to contribute and share the
> work.
>
>
> Ari Maniatis
>
>
>
> [1] http://security.freebsd.org/
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001   fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>
>
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>