[TYPO3-core] Fixing no-brainers?

[Martin Kutschker]

Michael Scharkow <michael at underused.org> writes on 
Mon, 10 Apr 2006 11:32:49 +0200 (METDST):

> Martin Kutschker wrote:
> 
> > Let's start with fixing a couple of urgent stuff in 4.0.1 and
> > possibly 4.0.2. Better have a 4.0.1 in one week and 4.0.2 after
> > that
> > in three weeks than only one 4.0.1 in two months.
> 
> Unless there's really urgent security or blocker (EM not working,
> etc.) bugs, I'd rather not release 4.0.x too often because updating
> is a pain.


Then simething IS broken with our update mechanism. Upgrading from x.x.N to x.x.N+1 should be jus a matter of changig the source-symlink!


> > Parallel to 4.1 we could work on the BE UI overhaul that's the goal
> > for 4.5. I think we should in this case don't work on HEAD, but in
> > either a branch or on local systems so the tree doesn't get
> > destabilized. Since these changes will be major and will take more
> > time I suggest work on this will be started before the release of
> > 4.1
> > (hence the new development[!] branch that is to be merged into
> > HEAD).
> 
> I'm not sure I agree with this. What do we have head for if both 
> bugfixing and the 4.5 stuff go into branches? With the new roadmap 
> things will get very complicated if we really want a big-bang 4.5 
> release with no intermediate steps. Why shouldn't we continue in
> HEAD, the CVS guidelines are strict, so we can expect that nothing
> will break.


Why? Think of someting big as verisioning or any refactoring. You cannot commit this to the CVS bit-by-bit without breakig the tree. So you have to do a big-bang landing on the HEAD.

Of course you could work alone on your own tree at home, but I gather that we want to cooperate efforts. So in my opionion it'd be fine if we head one branch with strictly UI.overhaul changes (and NO other changes at all!) that gets merged into HEAD again after 4.1.

Masi