[TYPO3-core] RFC: Hook request in t3lib_tceforms

[Thorsten Kahler]

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

Hi Ingmar,

Ingmar Schlecht wrote on 15.02.2007 11:31:
>> AFAIR the last discussion on the core list had the conclusion that a RC
>>  means a new branch. I support this.
> 
> You probably missed the discussion in the thread "4.1 - How far are we?" 
> about whether to create the 4.1 branch with the release of the RC1 or 
> with the release of 4.1 final. I share Stucki's view there.
> 

I didn't miss it but I also didn't have it in mind when I wrote the above.
Maybe someone else someday might not have it in mind when committing a change.

What does that mean for our team?
a) I'm too oblivious for the team
b) Comments in a thread longer that's too long to fit on a screen can't be
the guideline for the team

If it's either one of the above IMHO it's better to tend to the "technically
correct" way mentioned by Stucki.

>> I think there's no discussion about following points: - A RC means a
>> feature freeze. - A feature freeze does allow no changes but bug fixes.
>> 
> 
> The feature freeze before a minor version means no changes except for 
> bugfixes and hooks.
> 
> Yet, new hooks are not allowed for patchlevel version.
> 

Agreed, hooks might get in after the feature freeze but not after the
release of the final minor version. I didn't have Ingos fine argumentation
at hand when I wrote my post (while on the train).

>> - No new features but only bug fixes can get into a branch.
> 
> ...which doesn't apply for hooks if they're added before a final minor 
> version.

Yep, see above.

> 
>> What's the result of this? If we have a RC _without_ a branch, it's not
>> allowed to do any other changes on trunk than in a branch. So there's
>> no difference between the trunk and a branch. And we have the absurd
>> situation of the trunk being a branch.
> 
> Exactly. There's no problem with that, as discussions about new features 
> should be held back until 4.1 final is released, so we need no "trunk" 
> (in the original sense) during the RC phase.
> 
>> Ergo: RC => feature freeze => branch
> 
> See above.
> 

IMHO it's not only technically correct but it also might support developers
to commit to the correct branch / trunk depending on the kind of change. And
it's easier to merge bug fixes from a branch to the trunk (or commit them to
both as it should be our daily practice) than to remove new features from
the trunk and introduce them again after a later branch.

>> [snip]
> 
> I wouldn't object to adding that to the core team guide, yet hooks should
> be explicitly allowed until final.

Agreed.

> 
> Anyway, I think that a majority vote or sensible arguments of the release
> management can in any case make exceptions to what's written in the core
> team guide, as sometimes special cases might not be covered properly.
> 

I think the whole discussion is about our "default procedure" albeit special
cases.


Regards
Thorsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFF1EHtmfCxYiz3uLkRApK4AKCAlJw+utANZjdBgCE18lhGt5b2uACfaNl/
ubIj9YykEkxPN4ljMeB4eIE=
=IJoV
-----END PGP SIGNATURE-----