[TYPO3-core] Release-Cycle and Maintenance-Policy of TYPO3

[Jigal van Hemert]

Hi,

Thanks for posting this. It's a subject where the current situation is a 
compromise of compromises. It's also an area where the current situation 
will have disadvantages to just about everybody.
If someone has the perfect alternative that would be worth considering 
of course.

On 11-5-2012 10:27, Mario Rimann wrote:
> For us (www.internezzo.ch) as a mid-sized TYPO3 agency with no
> inhouse-core-dev, the current release policy (6-month cycle) is
> sub-optimal since it cuts down the “lifetime” (as in “time covered
> with at least security updates) of a TYPO3 website from about 3 years
> to about 1.5 years (compared to the pre-6-month-release-cycle). I know

As Georg indicated the "no inhouse-core-dev" really has nothing to do 
with the lifetime of an installation. Some agencies use patched cores 
for their customers, but a lot of them (with or without core devs) don't 
do that.
I personally only do backports of bugfixes in patch level releases if it 
is a really big problem for a customer. And once I did a backport of a 
feature (two hooks, still features :-) ) because we really needed that 
to implement the desired functionality and the next release was still in 
alpha.

> that back then, I raised this concern and (if I remember correctly)
> talked to Michael Stucki at that time and I guess others did, too –
> and shortly after that an LTS version was announced. This LTS version
> was/is great as it improved the situation a bit.

Many people seem to think that the LTS version was to give customers a 
choice between a longer support period and new features. Originally the 
reason was that everybody was fed up with spending so much time on 
finding workarounds for IE6. Microsoft has a support policy and part of 
that is that they will support the products they ship with a Windows 
version as long as they support that Windows version.
Extended support for XP ends in spring 2014 and thus IE6 will be 
supported until spring 2014.
TYPO3 4.5 is the last version which supports IE6 for the backend. This 
means that essential functions will be working, there is IE6 specific 
styling, special GIF sprites for the icons, etc.
The support for TYPO3 4.5 will end when Microsoft (finally) drops 
support for IE6.

> But what we want to be able to offer to our customers is a
> long-lasting solution where the time from “buying a website” until
> “having to spend money on the website again for an upgrade” is as long
> as possible.

That is also something *you* (= agency) could offer to your clients. If 
you use well maintained extensions, keep a close look at the deprecation 
log you can minimize the risk for an upgrade.

[... comparing versions and upgrades ...]

An agency could also offer their clients a 3-year "free" update 
solution. The situation you describe is that your clients just benefit 
from what is offered by TYPO3 as a base product.

I'm not saying that upgrades and support are completely your (agency's) 
problem, but it's also wrong to say that "they" (TYPO3/core team/...) 
should provide the support for your clients for free.

> - have a longer supported-time (only regarding security fixes!!) than
[...]
> - have more LTS-versions – it’s not about how fast the next LTS is
> released rather than increasing the overlapping lifetime of two LTS
> releases

This both means more versions to support (even for bugfixes and/or 
security fixes). More versions to support means a lot more work. Many 
fixes are not simply cherry-pick backports. Fixes touch areas where 
features are included and this affects the solution.
There is already a long list of patches waiting for reviews (including 
backports) and a long list of issues waiting for a solution or at least 
a check to see if the report is really an issue.
This will only grow if we need to support more branches.

> We know that both having more LTS versions and in general increasing
> the lifetime of any release will “cost” manpower. But from discussions
> with several persons I know that just throwing money at it is no
> solution itself (since the developers/testers are missing to actually
> *do* the (probably paid) work).

To some degree it would help. There are enough freelance developers who 
could be hired to do core work. At the moment there are some freelance 
devs who do core work in their own time. The rest of the week they do 
client projects, partly because they have to make a living.

> I don’t expect a wonder or that the core-team now changes the whole
> release cycle 180° - but maybe you can take this input into your next
> meeting(s) and the mid-term planning somehow where it hopefully has
> some effects :-)

The current 6 months cycle is a trade off of course. On one hand there 
are small features (such as hooks) and fixes which need a setting or 
imply a breaking change (in some extend); these need to go in major or 
minor releases. If you need to wait a year for such a small feature that 
would be problem to a lot of agencies and customers too.
If we need to support more branches then the work load would increase 
too much. At the moment we have to apply a bugfix to four branches 
already (most of the time). If it isn't a straight backport (no code 
changes in the are of the bugfix between the branches) these backport 
also need reviews.

For extension the developers the situation becomes also more complex if 
more branches need to be supported. Longer support for version means 
that extension developers either cannot use new functionality, or have 
to use compatibility checks, or maintain several versions of their 
extensions for different branches.

This was not meant as a series of arguments against longer support 
periods, but there are pros and cons to everything. If we can find a 
solution which provides better support for clients and can be maintained 
that would certainly be worth considering.

-- 
Jigal van Hemert
TYPO3 Core Team member

TYPO3 .... inspiring people to share!
Get involved: typo3.org