No subject

later as many more problems will arise on upgrades, where you skip an intermediate LTS.
So I would actually only allow upgrades from LTS to LTS.

The cons listed under the second item in the "current state" section of the blueprint actually are not changed by the new release cycle.
Example: "new features need to be well tested and rock solid"; Well that's what everybody is expecting from new code, right?
This expectation does not change just because we do have more LTS releases now or because we have EAR releases.

The benefits for core development listed are actually also the biggest drawbacks:
"contributors to the TYPO3 CMS can concentrate on only a couple of features for single snapshot releases"
   While I really appreciate a move to a more focussed working process, I really do fear that the most important value of
   an enterprise product "support" (includes bugfixes) is even more neglected as the focus is on new features more than ever. (see also my comments further down)

"less versions need to be maintained for TYPO3 CMS"
   Well, if I'm counting correctly that is always 3 versions at a time. Currently we theoretically maintain 6.3, 6.2, 6.1, 4.7 and 4.5... theoretically;
   practically we do maintain 6.3 and 6.2 and occasionally take a look at 6.1. 4.x is rather ignored currently, although these could really
   deserve some focus to improve the still really hard path of upgrading to 6.2. So actually we do maintain one more version in the future.
   
"Bigger features are prepared in feature branches"
   Easier said than done. We lack proper infrastructure support for such a branching model. Of course we can switch from the cherry-picking approach to
   a github similar system. But that's a different topic. Still we should have an estimate on the impact of this idea.

   
The "pre-EAR" phase is nothing but a nice name for what had been done anyway for each release in the past.
So nothing new or beneficial here.

Version numbers
===============
If you ignore the specifics of the version numbers for a while and read the description of "Impact on core development workflow",
one can actually map this 1:1 on the current version number scheme.
The deprecation information is nothing but an extension of the period a deprecated method stays available. Currently we remove code
after two releases (so once a year), in the new time scheme this would happen once every 1.5 years.
What is elaborated on breaking changes also applies to the current version scheme, except that we grant ourselves now to do breaking
stuff much more often, every 1.5 years. This is a really positive move, as this really eases development to get things further.

The documentation requirements have nothing to do with the release cycle. The proper documentation has actually been missing currently
and should be required no matter which version numbers we use.
Same goes for the "public API" part.

Regarding the EAR name, I'm with the posters on the discussion list [3] that this name is not perfect. I know you would like to suggest "stableness"
with the new name, but please see my note on "stable" further down. Everyone knowing TYPO3 CMS really good, knows that stable releases are unlikely.
I'm not seeing an argument in this scheme that actually improves the stableness, so I'm eager to be proven wrong here.

Git commit message
==================
I'm still not fond of the Releases: master line.
Example: A feature is merged in 7.2 EAR having of course only "master" in the releases line.
Some time passes and in 9.1 I look at the commit and into the history of 9.1 and ask myself "What was master back then?"

What I'm missing
================
 * A word from the marketing team, whether this actually sells and how they are involved in this change.
 * There should be coordination on which tasks is being worked already before the stabilization phase, where an RM jumps in. (Prioritize stuff!)
 * Estimation of time required to implement all these changes. (typo3.org, Wiki-Pages, Docs, Workflow descriptions, propagation of the new release system to the outside world (news articles, media contacts), etc)
 * Who takes care of all this organizational stuff as it involves quite some areas and needs to be changed rather timely?
 * Who defines when the merge-windows opens?
 * When / How do we elect the new RM? At ACMEs? Before the current LTS is released or after that?

One might say that some questions are "only details", but to me - and maybe also for others - these are important details.

Existing important problems not solved by the new versioning scheme
===================================================================
 * How to motivate people to actually do the ground work, mainly bugfixing?
 * Who is steering the contributors while the RM is not yet active (before the merge-window)?


"Stable" - and my impression of the current state of TYPO3 CMS
==============================================================
While we made huge progress with the 6.2 release and really got a lot of stuff towards an acceptable state, I tend to get allergic on the word "stable". 
Actually, I can't hear it any more. We throw around this word all the time, defining an LTS as stable, the intermediate versions as "stable too",
and each bugfix release is a stabilization-release.
My honest impression: TYPO3 CMS is miles away from anything I would call stable, especially in terms of enterprise level!
Don't believe me? Have a look at the really hard nuts in Forge nobody dares to touch. Lots of things broken, which had been working before.
These are bugs, carefully reported by users, which are not easy to grasp in a second. The current way of handling those bugs can be easily described: Let them rot.
Without having been physically present at the events in the last months, I have the feeling that big motivation is present and also
some people tend to share the same or a similar vision (again). But this motivation is entirely focussed on vastly changing stuff or introducing new fancy things.

What needs to change
====================
Instead of getting our foundations and the must-haves for a CMS right (DataHandler, typolink, FAL, etc, etc) we build fancy stuff on top.
We try to repaint our facade (composer, release cycle, etc) while the building below is still moving around in the building pit.
Of course we do have too many building sites to work on, but we do know as well that working on tasks in parallel is not as efficient as when serializing the work.

That said, I really ask you to trim the management plan for TYPO3 CMS towards focussing the work and concentrate it on the (boring) basics.
Getting 2 or 3 people working on the same small set of (even hard) patches really gets things forward (the sprints proof that everytime).
IMO this is really only possible if there's one person elected to take the steering wheel. A person who is up to date which pressing tasks are on the list and a person that
is respected enough such that he/she is able to steer the group of contributors through the tasks to be done.
We only gain (back?) acceptance in the PHP world if we ship a stable product, and that involves the boring work of building the foundation and fixing bugs.

With the current release cycle proposed, I really fear that we - as ACs - drop apart even more and that the good work done
by each individual contributor is just rotting away in technological sinks as it is not ready yet, but nobody takes care.
(Obviously I'm not alone with this fear. Jigal expressed this too in [1])


Summary
=======
The last section got a bit off-topic, but it reflects my overall thoughts.
Because of all this, I'm not able to positively vote for the concept in this state, although I would appreciate some ideas of it at lot.
I would really appreciate concept suggestions how we could tackle some of these fundamental problems:
 * Build a matching vision for the product. At least within the ACs.
 * Bring back responsibility of developers. (see failed Friendly Ghost concept)
 * Find a structured way to handle the everyday work of bugfixing. (hence get the number of open issues down; gerrit and forge)

Thanks for reading.

Sincerely,
Markus Klein



[1] http://forum.typo3.org/index.php?t=msg&th=204519&goto=713634&#msg_713634
[2] http://forum.typo3.org/index.php?t=msg&th=204519&goto=713735&#msg_713735
[3] http://forum.typo3.org/index.php/t/204519/
-- 
Kind regards
Markus

------------------------------------------------------------
Markus Klein
TYPO3 CMS Active Contributors Team Member