ATS support cycles

[Arno Töll <ar...@debian.org>]

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

Re: ATS support cycles

[Igor Galić <i....@brainsware.org>]

----- 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.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515  2EA5 4B1D 9E08 A097 C9AE