I guess that's fair.

On Wed, 8 Jul 2020, Nicolas Motte wrote:

> Thx Dormando!
> I ll then use this rule for the time being:
>
> - 1.4 is dead
> - 1.5 is still supported (in the sense that a major security issue could be 
> fixed)
> - 1.6 is the preferred version 
>
> Cheers
> Nico
>
>
> On Wed, Jul 8, 2020 at 9:51 AM dormando <dorma...@rydia.net> wrote:
>       Hey,
>
>       In extreme cases we would provide patches, and there's nothing stopping 
> me
>       from releasing a new 1.5 version. Most distro's just patch what versions
>       they maintain, which is a wide swath of them.
>
>       The only difference between later 1.4 and early 1.5 versions were the
>       defaults enabled, so releasing more 1.4's had no point.
>
>       I think the one CVE that's happened since 1.6 came out only affected 
> 1.6+.
>       1.6 is also not a huge jump.
>
>       In short, nobody's asked for one, so I havent't done one, I guess. The
>       project moves pretty slowly and conservatively so I don't personally 
> view
>       the dot versions to be something people should hold onto dearly. It just
>       makes things harder when something goes go wrong since they have less
>       observability and miss out on bug fixes.
>
>       On Wed, 8 Jul 2020, Nicolas Motte wrote:
>
>       > Hi everyone, 
>       > I d like to know what is the end of life policy for major memcached 
> versions.
>       >
>       > At the moment we re using 1.4 and 1.5. Looking at the release notes, 
> it feels like only the latest major version (1.6) has new releases,
>       which makes me
>       > think in case of a security issue found on a previous major version, 
> it would not be fixed and we would have to migrate to 1.6.
>       >
>       > It would mean the policy is simple (but a bit drastic) : "every time 
> a new major version is released, the previous one is dead."
>       >
>       > Is my understanding correct?
>       >
>       > Cheers
>       > Nico
>       >
>       > --
>       >
>       > ---
>       > You received this message because you are subscribed to the Google 
> Groups "memcached" group.
>       > To unsubscribe from this group and stop receiving emails from it, 
> send an email to memcached+unsubscr...@googlegroups.com.
>       > To view this discussion on the web visit
>       > 
> https://groups.google.com/d/msgid/memcached/CAB7O_Y_BN%2BewH-z%3DqCe2LGMU_Qj7nuZ9fHp9K-jWsDrbUhfTLQ%40mail.gmail.com.
>       >
>       >
>
>       --
>
>       ---
>       You received this message because you are subscribed to the Google 
> Groups "memcached" group.
>       To unsubscribe from this group and stop receiving emails from it, send 
> an email to memcached+unsubscr...@googlegroups.com.
>       To view this discussion on the web visit 
> https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.2007080043570.18887%40dskull.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups 
> "memcached" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to memcached+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/memcached/CAB7O_Y-XUJhyL-gVmCGHfRDTqqHvSvpD6A4xzPjmA_B%2BF6B-6Q%40mail.gmail.com.
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to memcached+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.2007080144460.18887%40dskull.

Reply via email to