Hello, raising this discussion from IRC to a wider audience: I've been briefly discussing your ATS release cycles with Leif and Igor. Generally you aim a 6+ month release cycle for stable releases. Your current time line is to release 3.2 in April or May I think, with 3.4 successively following in October.
While this is perfectly legit and entirely up to you, I was wondering how long you plan to support any given major stable release. I'm asking because I realize this creates a substantial amount of work to you, as every supported release produces lots of backports and maintenance work over time. Therefore, I'd suggest to keep the amount of stable releases at the same time rather low. Keep in mind, you're adopting the httpd release cycle and they still support httpd 2.0 and 2.2 with 2.4 being generally available since recently. However, httpd 2.0 was released $long_ago, roughly 10 years if I'm not mistaken and that's a _long_ time if you plan to do it likewise (or even approaching a life span coming somewhat close to that) for ATS as that would imply to support lots of releases at the same time at some point. Right now you officially support 3.0.x with 3.2 upcoming and someone even claimed 2.x was never EOLed either. Now I wonder: How long do you plan to support a major stable release (3.0, 3.2, 3.4, etc.) and could you maybe document your choice somewhere? On behalf of Debian, where I act as a ATS maintainer I'd of course like to see a life span which covers a Debian release cycle (roughly 3 years in total per release), and I guess enterprise customers - think of RHEL - would like to see something along that line as well. Given ATS is something used on servers, I do think fast release cycles are not necessarily something demanded by site administrators. Actually, users of RHEL even found their 6 year support cycle not long enough. I didn't meant to imply you shouldn't release as often, you can of course do stable releases as often as you like and you can feel Ubuntuish, but you should do so by keeping prior released versions in mind. What do you think? I'm merely reporting from a user or maintainer perspective - not yours with a developer hat on. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D
signature.asc
Description: OpenPGP digital signature
