On Jul 5, 2013, at 3:52 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > On Fri, Jul 05, 2013 at 10:59:59AM -0400, Chuck Lever wrote: >> >> It feels like we should have a plan for both the server and client. > > That discussion brought out of the woodwork a couple people still > claiming to depend on v2. They seemed to only care about the server > side (because they had some old (non-linux) clients that were still > using v2 for some reason). > > There could be other cases of people depending on an application tied to > an obsolete client OS that still expect to be able to upgrade their > server. > > I may be wrong, but I'd expect the same situation (needing an obsolete > server to be able to access some data) to be rarer. (One possible > exception I noticed is vesta: http://www.vestasys.org/--source-code > management system with built-in v2-only server. Wonder if it's still > alive??) > > Anyway I'm inclined to treat dropping server protocol support by the > same standard as we'd treat dropping kernel ABI: as in, it's only OK if > we don't expect anyone to notice. I'm wondering why this requirement does not also apply to the client. I've heard the opinion expressed recently that we really should not deprecate a feature that still has users. It might be reasonable to bring this question up on lkml, specifically in the context of NFS version 2. For the sake of argument, what would induce us to keep NFSv2 in the client? Finding someone to maintain it? -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
