----- Original Message ----- > 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.
Couple of thoughts. Id like to support 3.0.x throughout 3.2.x and retire it when we release 3.4.x That means, no more bug fixes, no feature back-ports, etc.. We *could* back-port security fixes throughout 3.4.x I'm not exactly sure what this phase would be called. EOS? EOL? I'd like to leave this option open - and invite everyone for their opinion. Please remember that managing 3 or 4 trees is not fun. I'm going to point everyone who thinks otherwise to the apr project for references. As far as time frames go, we'd be in a two year support frame with these options. Frankly, I'd rather *not* support anything for six years. Much changes in six years. Code base, developers. Systems, and compilers. My thoughts and opinions, not necessarily those of the PMC. At least not until we've agreed on them ;) > -- > with kind regards, > Arno Töll > IRC: daemonkeeper on Freenode/OFTC > GnuPG Key-ID: 0x9D80F36D i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
