The release policy is based on an LTS release every 18 months, and a stable version every 6 months (ie. two stable releases between each LTS). The scheme is intentionally spaced when necessary in order to reflect reality. There has been almost 2 years between v5.0 and v6.0, which is why we have not made any stable versions in-between and we released directly an LTS. We’ve also had one year between v6.0 and v6.1, meaning that our next release will be directly the v7.0 LTS and not the v6.2. This choice is made to satisfy customers who have been waiting a long time and want to upgrade directly to a LTS. We try to respect the timeframe between each LTS (~ 18 months) meaning that the stable versions play more of a secondary role. Our focus is a new LTS every 18 months.
Consider some specific cases, for businesses <25 users; the Enterprise contract clearly states that it covers only their current version + 1 next LTS. (the largest contracts cover the current version + 2 LTS seq.) Specifically, this means:
* Client 1 (currently v5.0):
This customer is covered up to the release of v7.0. Indeed, it covers + 1 LTS version, so covered in v5.0 and v6.0. So when v7.0 is released, client 1 should only migrate if he wants to continue to receive services from the Enterprise contract. It’s not required or mandatory. If he’s satisfied with v5.0 and has met only few bugs, he’s free to stay on. The only disadvantage is that the day he encounters a blocking bug, he will either need to migrate, ask OpenERP on how to fix it with some hours of support, or ask his official partner to fix it for him. At that point, it’s quite natural to ask client 1 to migrate, especially if he wants to continue to be maintained. If he does not, he is free to, but it will cost more later.
OpenERP realizes that migration takes time (backup, migrate, test, train, migrate modules customs …). That is why we will leave a 5-month period (from the date of release of v7.0) for which we continue to maintain (bugfixer) v5.0, the time for the client to do his migration. The bug fix on V5.0 will then stop 5 months after the release of v7.0.
=> Client 1 has now ~7 months to migrate (~ 2 months to the LTS release of V7.0 + 5 months of flexibility offered)
= so the bugfix on v5.0 will last for another 7 months (max until 01/06/2013)
* Client 2 (currently v6.0):
This customer is covered up to the release of V8.0 (+ 5 months margin in order to prepare for the migration in which the bugfix is always covered)
=> Client 2 has now ~ 25 months to migrate (~ 2 months for the release of the LTS v7.0 + ~ 18 months for the release of LTS V8.0 + five months of flexibility offered)
= so the bugfix on v6.0 will last for another 25 months (max until 01/12/2014)
* Client 3 (currently v6.1):
This customer is covered up to the release of the next version, because v6.1 is not a LTS, their warranty period ends with the release of the next version. Therefore its maintenance contract covers up to the release of the v7.0 (+ 5 months margin to prepare his migration in which the bugfix will always be covered).
=> Client 3 has now ~7 months to migrate (~ 2 months until LTS releaseV7.0 + 5 months of flexibility offered)
= The bug fix on V6.1 will last for ~ 7 months (max until 01/06/2013).
* Client 4 (starts his project with V7.0):
This customer is covered up to the release of v9.0 (+ 5 months margin to prepare for the migration in which the bug fix is always covered)
=> Client 4 has ~ 41 months to migrate, starting from the release date of V7.0 (~ 18 months until release of LTS V8.0 + ~ 18 months until release of LTS V9.0 + 5 months of flexibility offered)
= The bug fix on v7.0 will last for ~ 41 months (max until 01/04/2016)
Indeed. Shine IT don't need yet another badge or certificate to prove its capability of doing OpenERP project, as all the team members here have more than 4 years' hands-on experience with OpenERP and are the driving...
Every day, executives at small and midsize companies make critical business decisions based on uncoordinated information from a variety of sources: opinions from peers and colleagues; a personal sense...
A Next Generation Opensource business model have build the Next Generation ERP, OpenERP meets all many features to become meet next-generation Enterprise Software.
Here are the parameters to be a next...