policy change related to kdelibs snapshots

[Dirk Mueller]

On Monday 10 July 2006 17:12, Cornelius Schumacher wrote:

> I'm not sure, if you meant it this way, but I think it would be good to
> have bleedingedge for all modules including kdelibs.

I'm against that. if there is big restructuring going on (e.g. LiveUI), it 
should happen in its own branch. If its smaller stuff, it should happen in 
trunk. Those with the powerful build clusters (and the committer himself) 
will be able to fix the failures. 

> This way new features 
> and API changes can be developed without affecting application developers
> who prefer to work on a stable version of kdelibs.

The major pain that was caused by the snapshotting (and the 
instability/porting errors) in trunk is that there were a lot of unrelated 
changes bundled together and suddenly being flood over all of the tree due to 
a snapshot update. This caused a lot of hectic fixes done by script porting 
and the resulting instability. 

Doing so in trunk would make things at least somewhat easier to track again, 
because one doesn't have to remember what particular API changed almost two 
weeks ago in which way. 

Developing in trunk also means that you can influence when to update: if you 
only have one hour left of hacking before the day ends, just don't update. 
Re-compile over night. The snapshot update sort-of forced you to do that 
though. 


Dirk