From: Fredrik J. <jer...@sq...> - 2007-02-12 00:22:06
|
I was reading some thread before, where someone was asking for how long we supported the various versions of SquirrelMail. I got a little curious, so I dug up the release dates for the current branches. As far as I know there's no official policy regarding how long a version is supported. If we support all releases not older then six months, we'd end up supporting 1.4.9 and 1.4.9a. I think that six months is a fair amount of time for supporting older versions. Naturally we should also support the latest version even if it's older than six months. What are your opinions on this? Do you have other suggestions? Should we make this an official policy? SquirrelMail 1.4.0 2003-04-03 SquirrelMail 1.4.1 2003-07-07 SquirrelMail 1.4.2 2003-10-01 SquirrelMail 1.4.3 RC 1 2004-05-10 SquirrelMail 1.4.3 2004-05-30 SquirrelMail 1.4.3a 2004-06-02 SquirrelMail 1.4.4 RC 1 2004-12-31 SquirrelMail 1.4.4 2005-01-22 SquirrelMail 1.4.5 RC 1 2005-06-15 SquirrelMail 1.4.5 2005-07-13 SquirrelMail 1.4.6 RC 1 2005-12-10 SquirrelMail 1.4.6 2006-02-23 SquirrelMail 1.4.7 2006-07-04 SquirrelMail 1.4.8 2006-08-11 SquirrelMail 1.4.9 2006-12-02 SquirrelMail 1.4.9a 2006-12-03 SquirrelMail 1.5.0 2004-02-01 SquirrelMail 1.5.1 2006-02-19 Sincerely, Fredrik |
From: Paul L. <pa...@sq...> - 2007-02-13 06:59:45
|
On 2/11/07, Fredrik Jervfors <jer...@sq...> wrote: > I was reading some thread before, where someone was asking for how long we > supported the various versions of SquirrelMail. I got a little curious, so > I dug up the release dates for the current branches. As far as I know > there's no official policy regarding how long a version is supported. If > we support all releases not older then six months, we'd end up supporting > 1.4.9 and 1.4.9a. I think that six months is a fair amount of time for > supporting older versions. Naturally we should also support the latest > version even if it's older than six months. What are your opinions on > this? Do you have other suggestions? Should we make this an official > policy? Cor has a very very good point on that other thread. Although I liked Chris' keep-it-simple approach, there are possibly hundreds (more?) of institutions that will be using older versions of SM for longer than six months to be sure. They very well might be using the security patches to keep their systems up to date, but I don't know that they will otherwise upgrade on any schedule imposed by us. On the thread about security patch maintenance, Jon proposed a system that provided patches for versions going back a lot more than six months, so there are definitely other ideas out there beside the six-month one. As for supporting bugs/requests that involve non-security related parts of the code, sometimes it is easy to help people identify/fix issues even on older versions, but sometimes it is very much a waste of our time, so I'm not sure what the best answer is... right now, it seems to be somewhat ambiguous (aside from not supporting 1.2.x), in that we prod people with things older than about 1.4.4 to upgrade, but generally don't refuse to help anyone with a semi-recent version of 1.4.x (1.5.x is treated a bit differently, but that's probably an easier question to answer). > SquirrelMail 1.4.0 2003-04-03 > SquirrelMail 1.4.1 2003-07-07 > SquirrelMail 1.4.2 2003-10-01 > SquirrelMail 1.4.3 RC 1 2004-05-10 > SquirrelMail 1.4.3 2004-05-30 > SquirrelMail 1.4.3a 2004-06-02 > SquirrelMail 1.4.4 RC 1 2004-12-31 > SquirrelMail 1.4.4 2005-01-22 > SquirrelMail 1.4.5 RC 1 2005-06-15 > SquirrelMail 1.4.5 2005-07-13 > SquirrelMail 1.4.6 RC 1 2005-12-10 > SquirrelMail 1.4.6 2006-02-23 > SquirrelMail 1.4.7 2006-07-04 > SquirrelMail 1.4.8 2006-08-11 > SquirrelMail 1.4.9 2006-12-02 > SquirrelMail 1.4.9a 2006-12-03 > SquirrelMail 1.5.0 2004-02-01 > SquirrelMail 1.5.1 2006-02-19 > > Sincerely, > Fredrik |