Re: GNU sed

[Eric Blake]

On 07/19/2017 03:33 AM, address@hidden wrote:
> 
> Hi,
> 
> Can you please tell me the latest version of GNU sed and what is its EOL , 
> can you please also tell me the EOL of the previous versions.

The latest version is always listed here:
https://www.gnu.org/software/sed/sed.html
http://ftp.gnu.org/gnu/sed/?C=M;O=D

currently 4.4

The EOL of open source software is a tricky thing to predict - there is
no fixed release schedule, and therefore, all the more we can promise is
that a version is not EOL until the next version is released.

That said, if you need more guarantees than what upstream is willing to
provide, you are always welcome to open a contract with a downstream
enterprise distro to guarantee support for a particular version.  For
example (although you'll note that I'm biased based on my email
address), you could sign up for a Red Hat Enterprise Linux contract, at
which point you are guaranteed that your particular pre-built version of
sed shipped in that distro is supported for as long as that distro is
supported, regardless of what upstream does in the meantime.  For
example, RHEL 6 ships sed 4.2.1, and since RHEL 6 is not EOL, then Red
Hat's build of 4.2.1 is not EOL, even though here on the upstream list
we will probably ignore any bug reports against that version unless you
can also reproduce the bug in the latest upstream version (that is, by
using a downstream distro, your bug reports should go to that downstream
vendor).

I'll also note that you've already asked this question on the M4 list
(http://lists.gnu.org/archive/html/m4-discuss/2017-07/msg00002.html),
and received the same answer.  You can probably expect similar responses
for many other GNU and non-GNU open source software. I'm not really sure
what you're after, but if you want reliable, date-guaranteed support,
opening a support contract with a downstream vendor is a much better
approach, as that is not something that upstream cares about.  Yes,
upstream tries to avoid regressions, and release as needed when fixes
are added, but with no fixed schedule, no one upstream is willing or
even able to make firm guarantees; after all, the GPL has this bold
statement about a disclaimer of warranty:

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM ``AS IS'' WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND
PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE PROGRAM PROVE
DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
CORRECTION.

It is not until you get to downstream vendors, where you have an
explicit contract that adds additional guarantees on top of what
upstream provided, that you start to have any recourse for guarantees
about software lifetime.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature