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

[Steffen Gebert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Michi,

nice to hear that you discussed all those important things!

I'm happy to say that I agree with you in all major points. It perfectly
fits my personal opinion.

> Therefore we decided to skip the whole part from our proposal, and
> instead refer to 6.2 + 1, +2, etc. when naming versions.

I think that's not even needed. When we wrote "will be dropped with
4.8", it's okay to drop it in 6.0, as the version number is obviously
higher than the version advertised.

Kind regards
Steffen

- -- 
Steffen Gebert
TYPO3 CMS Core Team Member
TYPO3 Server Administration Team Member

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

I work for TYPO3 solely in my spare time. If you think that
my work helps you running your business, you are invited to
send me a donation via PayPal to this email address. Thanks

On 11/25/12 2:33 PM, Michael Stucki wrote:
> 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.
>>
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQsinsAAoJEIskG/rSlyw4bzkIAJYGe4T3aLX3xlx9bkvxvugw
2Vaq00gi6T7ukW1c8tNH7RZlNu141wpsW03Rwcn/mF0K7IEYEgXN0/1XZyW7lXgu
v6t/60L7ZmvKTBwBOZ2TezZLrJQB4n/zpoKcaipC8MwKYy6ZCUU9flCCe9S37U/i
Gek3/jF75lGkP47yOloAhYH+llY27odblcRutQHe3YJ3aoB1KCmJXKEcvvyYbMq2
AmkyiaiPqk/CMMcJdftHcp5AmjEI43UnKjvlae5k0jVJVw4kkBDGgg02XKTmWSk4
0POs2+Z8iF1Dc4S/ClCkjhAJtG/zlw9wqvyKKCIJ6Mz61nhPgpGdz2E6vp/Zij8=
=+4Y0
-----END PGP SIGNATURE-----