In announcing the new policy, Six Apart's primary goal is to help make Movable Type a safer and even more dependable product. In an effort to make it easier for our customers to keep their installed version of Movable Type up dated to the latest version of software, which provides the most effective form of protection against security threats, Six Apart has created the new "Product Life Cycle Policy." This policy is reflected retroactively including previously released version of Movable Type as well as all subsequent upgrades and new versions. We hope the following information will be helpful in getting your version of Movable Type updated to the latest and most secure version of the software available.
Product Life Cycle Milestones
Below are definitions for the different lifecycle phases included in the chart below
[GA (General Availability)]
During the period between GA and EOS (End of Sales), security patches and bug fixes will be released on a regular basis, with official technical support available for a fee.
[EOS (End of Sales)]
EOS designates the closure of sales for a specific product version. Major (x.0) and feature (0.x) releases for the product version released during the GA period will start to become available. Once EOS has passed, the product version released during the GA period will no longer be available for purchase. Bug fixes (0.0x) and security updates will continue to be released until EOM (End of Maintenance), and official technical support will continue to be available for a fee.
[EOM (End of Maintenance)]
EOM signifies the end of official Six Apart maintenance support for a specific product version. EOM occurs 12 months after EOS (End of Sales). At this point, the product version will go into what is defined by Six Apart as a security maintenance period: only patches for security breaches deemed critical by Six Apart will continue to be released until EOL (End of Life). It is possible to continue using the product at this time, however the user must understand that, following EOM, official technical support will no longer be available. In addition, only the latest version of the most recent feature release will be classified as EOM, with all previous versions classified as EOL (End of Life). If official technical support is necessary, the user will first have to upgrade to the most recent product release.
[EOL (End of Life)]
EOL signifies that a product version has reached the end of it's life span. It will no longer go under maintenance and will no longer receive bug fixes, security patches, or additional feature updates. Third party support may remain available, but there will no longer be any official Six Apart technical support. It is possible to continue using the product at this time, however the user must be aware of the security risk in doing so. It is strongly recommended that the user upgrade to the most recent version of the product before EOL occurs.
* Version Support Phase Chart
|MT4.2x||Aug 13th, 2008||Jul 29th, 2009||Jul 29th, 2010||Jul 29th, 2011|
|MT4.3x||Jul 29th, 2009||Jan 5rh, 2010||Jan 5th, 2011||Dec 31st, 2013
|MT5.0x||Jan 5th, 2010||May 25th, 2011||May 25th, 2012||May 25th, 2013|
|MT5.1x||May 25th, 2011||Sep 26th, 2012||Sep 26th, 2013||Sep 26th, 2014|
|MTA5.1x||May 25th, 2011||Dec 5th, 2012||Dec 5th, 2013||Dec 5th, 2014|
|MT5.2x||Sep 26th, 2012||Sep 30th, 2013||Sep 30th, 2014||Sep 30th, 2015|
|MTA5.2x||Dec 5th, 2012||Jan 15th, 20114||Jan 15th, 2015||Jan 15th, 2016|
|MTA5.2x||Dec 5th, 2012||Jan 15th, 2014||Jan 15th, 2015||Jan 15th, 2016|
|MT6.0.x||Oct 17th, 2013||Feb 12th, 2015||Feb 12th, 2016||Feb 12th, 2017|
|MTA6.0.x||Jan 15th, 2014||Feb 12th, 2015||Feb 12th, 2016||Feb 12th, 2017|
|MT6.1.x||Feb 12th, 2015|
|MTA6.1.x||Feb 12th, 2015|
This chart shows the dates of each phase (GA, EOS, EOM, EOL - refer to above definitions) for each version of Movable Type. Note that for Movable Type 4.38, the period between EOM and EOL has been extended from 12 months to 24 months.
Please send any questions concerning the product life cycle policy via following page:
Mike Johnson on January 13, 2013, 5:55 a.m. 返信
Sounds to me like a good policy that will save MT alot of time and money in the long run and will have a lot of users upgrading when the end of life cycle is complete.
I only wish more software makers would make such policies public so that its users and would be buyers could see when something is near or at its end of life cycle.
Wendy Carlyle on January 17, 2013, 7:22 p.m. 返信
The new policy makes sense. I believe in upgrading within a reasonable time after a product release or upgrade announcement. I’m sorry to admit that I am not an early adapter - I’m just a little more cautious. My brother, on the other hand, always wants the latest and greatest. Sometimes I wonder how we can be related.
Mike Stites on April 11, 2013, 1:55 p.m. 返信
Are developers automatically contacted when an older version reaches EOL or is it up to us to keep track of this? I generally wait until it is absolutely necessary to update so any bugs in the new version have time to get smoothed out.