[TYPO3-core] Changing the release cycle

[Steffen Gebert]

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

Hi Francois,

I see some problems because of the following facts:

(1) too much stress during stabilization phase
Xavier did it very well: The time between feature freeze and release was
pretty relaxed for the most people (at least compared to other
releases). Having two relaxed months to fix issues and kickoff new
projects is IMHO a very good thing. Unfortunately, it doesn't always
work like this. With 6.0, the namespaces thing required a lot of effort
("a lot" is probably underestimated for the immense work done by a
couple of people). Keeping the ambitions a bit lower would lead to
releases, which are obviously not that great, but keep developers more
relaxed.

(2) missing organization for next release
There was no kickoff for 6.1, even worse with 4.7. I think things like
release manager election and the first sprint have to be made / planned
before November. For 6.1, I guess this was not possible because of (1).

(3) bring features in early
after avoiding (1), it's easier to start big changes and submit them at
the beginning of the development phase - not at the end.

So honestly, I'm in favor of keeping the 6-monthly cycle. However,
please don't count my opinion too much, as I'm not active in development
anymore.

Kind regards
Steffen

- -- 
Steffen Gebert
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 2/16/13 1:07 PM, François Suter wrote:
> Hi all,
> 
> Some of you will maybe complain that I am single-minded, here I go again
> about the topic of the release cycle. Well, bear with me, please.
> 
> I think the six-month release cycle is partly responsible for our
> current problems. Is has put a lot of stress on development, as the
> window between kick-off and feature freeze is so short. Obviously this
> has the advantage of bringing about new features more quickly. That's
> why it was decided to adopt such a rhythm in the first place.
> 
> However it makes pretty hard to do bold and complicated changes, the TCA
> refactoring proposed by Christian being a good example.
> 
> Furthermore it puts a lot of stress on agencies, who have clearly
> clamored for a new LTS version.
> 
> It is also hard on extension developers. It's no small task to verify
> your extensions every six months, even if you maintain them regularly
> and thus should face few surprises.
> 
> I wish we would finally switch to a minor/major release development
> process. Benni set down the goal of general improvements for 6.1. This
> fits fine with stabilizing 6.0, which was a major and not so smooth
> release (we badly needed 6.0.1 and 6.0.2). Although still not announced
> officially, a consensus was reached to make 6.2 the next LTS version. In
> such a light, we should avoid important changes along the 6.x branch, so
> that we can adapt to 6.0 and then sail smoothly to 6.2. This version
> would not only be LTS but also the last of the 6.x branch.
> 
> In parallel, we would start working on 7.0, which could accommodate
> larger changes. A big argument against this has always been the problem
> of manpower and of developers maybe losing interest in the previous
> branch (6.x in this case). I think this is not a true issue. With the
> six-month release cycle we already have our hands full or versions to
> maintain. Furthermore if we assume that 6.x release are only minor ones,
> then they indeed require less manpower. Any feature developed for 7.0
> and which is considered minor, can simply be backported to the 6.x
> development.
> 
> I hope this proposal will not be brushed away too easily and at least
> foster some discussion on the release cycle, which I find frankly
> unbearable.
> 
> Cheers
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJRH5bZAAoJEIskG/rSlyw4t0gIAJQDStPEkyMi2rkbF+X7kyMs
uPMQ+sqz/8LxT8t6uwRzXReOaSE/IOngwfZzRhzfxiR+jIghjrpyH+Coz/dScCT1
I1HHSQtNV2SZ0HdGQU+VKZcyJ333BOzGE+EGqR/KGyGbuOYf+7FxM8bv44vWcH3C
2HDeFAoWRsEGjb5VLC1541CoflzWc+OOU+bFrhClapmiKhSYx7Cch943ESuNW1am
Aw2Qor0PZk9fzs+9NYlYMIMaVI1LTFf0V8e297YDnO7Z5PV8OWgrS9yYiB1dUgyg
Dj50QSwFEgCl6kdZ1o32ZPvWqcHZNqQVKN9lkRtfHx64IFeCbmIdsJ7UXFpriyo=
=lUvM
-----END PGP SIGNATURE-----