[TYPO3-core] Proposal for the upcoming Roadmap and LTS

Michael Stucki michael.stucki at typo3.org
Sun Dec 16 23:49:27 CET 2012


Hi all,

due to recent discussions, I'd like to make sure we don't decide on
something without having asked everyone.

So far, nobody objected to the proposal I posted below. We asked here on
the core team list, we asked the EAB of the TYPO3 Association (which I'm
a part of, too) and I also talked to several agency representatives [1],
and everyone agrees to it.

So this is your final chance to react if you disagree that we turn this
proposal into action. If I get no further responses until

Tuesday, Dec 18 2012, 18:00 CET

then I will announce it officially and publish the new roadmap on typo3.org.

Thanks for your support!

Cheers, Michael

[1]
http://lists.typo3.org/pipermail/typo3-team-core/2012-December/052932.html

Am 25.11.2012 14:33, schrieb Michael Stucki:
> Hi everyone,
> 
> this weekend I met with Benjamin and Oliver in Stuttgart to discuss the
> structure of the CMS core team and the upcoming roadmap.
> 
> We spent a major part of our meeting to review the whole discussion that
> started after Bennis proposal in October, and tried to identify the
> problems and fears that need to be resolved.
> 
> Looking at the huge discussion, there were a lot of similar views:
> 
> 1. There is a high demand for another LTS version
> 
> Only a few people have put this in question, whereas the only reason
> against another LTS seems to be lack of resources. We have tried to
> address that further down in this text.
> 
> 
> 2. Only six months to upgrade from 4.5 LTS to 6.2 LTS is too short
> 
> This was first brought up by Steffen Müller but a lot of people seem to
> agree to it. We see the need for this and would like to address it by
> extending the lifetime of TYPO3 4.5 LTS for 6 more months. That yet
> depends on Ernesto who is the release manager and needs to agree with
> it, but it looks like he will do so.
> 
> 
> 3. Don't backport _every_ fix into every supported version
> 
> This was brought up by Mario Rimann and I think it's a major point of
> the discussion where people talk about different needs:
> As an end user, I will most likely not care if some tiny change is
> backported to 4.5 LTS right now, however I do care if the blocker that
> prevents it to work with some new browser version is fixed. Therefore,
> we should clarify the maintenancy periods and separate between
> 
> a) regular small bugfixes
> b) priority bugfixes & security fixes
> 
> We think that a release should receive every bugfix at the time when it
> it is new (during the stable phase, 1st 6 months). But after that, there
> is no need to backport every change into a version. Only priority
> bugfixes (blockers, important issues) and security fixes (of course!)
> should be required for backporting. Other issues can still be backported
> optionally, we don't want to exclude this possibility of course...
> 
> 
> 4. Have the TYPO3 Association cover (some of) the costs for maintaining
> an LTS version
> 
> There were several feedbacks from people who seem to expect this. In
> fact, the maintenance costs are partly covered already as we do have
> budgets for important bugfixes. It is not clearly marked as a budget for
> LTS maintenance and it also wasn't used very often during this year.
> Also Oliver spent a large amount of time working on LTS releases, which
> has partly been covered by his team leader budget.
> 
> We will check if it is possible to modify our budget application to
> clearly address LTS maintenance, but even if not, the current
> application could cover some of these costs.
> 
> 
> 5. The 6 months release cycle should be kept
> 
> Again, there was only the lack of resource that seems to speak against a
> 6 month release cycle, but other cycles would have their drawbacks too.
> Therefore we think that it's good to keep it like it is.
> 
> 
> 6. Next major version / version numbering
> 
> We realized that it is not relevant right now if there will be a 7.0 and
> when. Both is possible but depends on factors that we can't foresee yet.
> 
> Therefore we decided to skip the whole part from our proposal, and
> instead refer to 6.2 + 1, +2, etc. when naming versions.
> 
> 
> Please take a look at the following sheet which explains how we propose
> the next versions to be maintained:
> 
> https://docs.google.com/spreadsheet/ccc?key=0AscRLPA1pqfQdEpUQVFVSjBQN1g5QnBQbTR5MmlJTXc
> 
> 
> Next steps:
> - We will write a proposal document that incorporates the points that
> have been covered here.
> - We will send this draft to the EAB of the TYPO3 Association and will
> ask for their advise on it.
> - We would like to publish a finalized version very soon, possibly
> before the release of TYPO3 6.0...
> 
> Greetings to all of you!
> Benni, Oliver & Michael
> 
> Am 06.10.2012 16:05, schrieb Benjamin Mack:
>> To all the contributors out there,
>> Olly, Michi, Helmut and me sat together during the T3CON and thought
>> about the next releases, after taking all the input from the community
>> we got from the last weeks and months. We made the following proposal
>> that we think fits best. BUT we want and need your feedback so we can
>> fine-tune and modify this proposal. Once we have a consensus I'd like to
>> publish a news article in the next weeks, and put up these points on the
>> Roadmap page of TYPO3.org so people know what they can expect.
>>
>>
>> We want to make the following suggestion:
>>
>> 1) We really want to stay in the 6-month-release cycle
>>  * it displays activity in our product
>>  * it is easier to get changes / features in
>>  * less discussions whether to merge features into existing stable branches
>>  * it has been proven to be a good way in the last 3 years.
>>
>>
>> 2) We want another LTS version
>>  * Depending on the criteria of a project, there is a high demand for
>> both (bleeding-edge features as well as long-term commitment)
>>  * Therefore we see a need to keep up with the LTS versions
>>  * A new LTS version shouldn't overlap too much with the existing one,
>> which will expire in Jan 2014
>>
>>
>> 3) Maintenance lifetime
>>  * Currently we support every release for 18 months, except the LTS.
>> This results in maintaining 4 to 5 versions at a time, which is a lot of
>> work for the Release Teams.
>>  * Therefore we suggest to only support the latest stable release and
>> its predecessor, starting with the release of 6.0 - which means approx.
>> 12 months for each version
>>  * There would be no change to the LTS maintenance lifetime (3 years).
>>  * The current stable release would get as much bug fixes as possible
>> (same as right now)
>>  * Other releases (predecessor, LTS) = get important and security fixes
>> (similar to how we deal with 4.5 right now)
>>
>> 4) We don't see the need for defining 7.0 version - yet!
>>  * We want to embrace 6.x just as we embraced and developed 4.x further.
>>  * We want stable and consistent 6.x versions to focus on
>> backwards-compatibility, maintenance and a high-quality product.
>>  * If it makes sense after a couple of releases to make breaking changes
>> or add large features, we are still able to raise the version number to
>> 7.0, but this is not the case yet :)
>>
>>
>> As a result, we propose the following schedule for the next versions:
>>
>> TYPO3 6.0
>>  * originally scheduled for October 2012, now postponed to November 2012
>>  * having all the goodies in there (Namespaces, FAL)
>>
>> TYPO3 6.1
>>  * Release in April 2013 (just 5 months to keep up with the release cycle)
>>  * It is just before T3DD13, to open up development for 6.2
>>
>> TYPO3 6.2
>>  * Release in October 2013
>>  * Marked as the LTS version, supported until October 2016.
>>
>> TYPO3 6.3
>>  * Roughly scheduled for April 2014
>>
>> Apart from that we don't want to announce a 6.4, 6.5 or even 7.0
>> versions (yet) because we don't really know yet where we will stand with
>> TYPO3 CMS and where Neos will be in early 2014. Let's not promise
>> anything that we cannot keep right now.
>>
>> Please think about it and tell us if you can agree with it via "+1/-1".
>> If you disagree, also tell us why, so we can try to improve the proposal.
>>
>> Michael, Olly, Helmut, Benni.
>>
> 
> 


-- 
Michael Stucki
TYPO3 Core Team member

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


More information about the TYPO3-team-core mailing list