Hi, On 30.04.2013 12:33, Daniel Gruno wrote: > This > would however mean that we have a two year support frame for released > products, which may or may not be enough for some people, so I'd be > interested in hearing what the users of ATS have to say about this.
Indeed. Debian (and its users) for example will get ATS 3.0 when the new stable version will be released presumably this week with its own 3 year cycle to start right then. Don't get me wrong, I am neither suggesting to adapt to Debian's cycle, nor do I expect volunteers to support lots of legacy releases. Even less I want to tell others how they should spend their spare time. I realize this is not doable. Therefore, supporting no more than two releases at any given time sounds legit and sane (in Debian we do so likewise by the way). I do think however, that we lack clear service level promises and documentation thereof, and perhaps some change in the release process. I already tried to find some consensus regarding ATS release cycles a year back [1]. Generally we aim to release a new stable version every 6 months, which is nice to developers who want to support a code base reasonably close to git HEAD, but given that the target user group for ATS are enterprises with larger clusters, they are less likely to move that often. Consequently, assuming we'd hold the 6 months cycle, a stable release would be unsupported after one year (not two as Daniel says), i.e. two releases ahead. That sounds like a lot of time for desktop users, and even more so for developers who'd rather cry about the outdated code rather than happily support it, but it's not a lot of time on the server user group where deploying a new release involves a 6 months test cycle on its own. As an anecdote, we are literally trying to transition since a YEAR (no, really) from HTTP 2.2 to 2.4 at Debian, because this is a very complex task involving work by lots of volunteers regarding third party modules and so on. ATS is not there yet and there aren't so many third party modules out there, but it could be some day and we should keep that in mind. We should find some trade-off, perhaps kind of a sunset model successively decreasing the amount of support granted over time (full support as we do today, core support for critical and security relevant bug fixes, security support only), and maybe release less often [2]. :-) YMMV of course. [1] <4f85b015.1060...@debian.org> [2] Although the 3.4 release takes longer than the promised 6 months anyway. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D
signature.asc
Description: OpenPGP digital signature
