[RFC] QA & Branching

[Jean-Paul Saman]

Good idea to have an experimental branch. 

Some other thoughts:
If it is decided to either merge regularly or merge some features with
the stable tree, then try to keep those  'merges' as small as possible.
In this way a single change can be tested quite fast and extensively.
Bugs can then be identified quite quickly and stability restored by
reverting the last change. 

Greetings, 
Jean-Paul Saman


Christophe Massiot wrote:
> 
> Dear friends,
> 
> Releasing a new version of VLC is now a mess ; it imposes several
> weeks of bug hunting during which implementing new features is
> dangerous. 0.2.91 has shown that despite all the time we invested to
> release it, we didn't have the right methods. 0.2.91 suffers major
> stability problems.
> 
> Besides, sam will (hopefully) soon check in a new video output which
> might break a lot of things for several weeks.
> 
> For these reasons sam and I would like to suggest an enhanced
> development method (largerly inspired by those in use in the open
> source community). First, we shall immediately create a new stable
> 0.2.92_BRANCH. This branch shall be intensively debugged, helped by a
> series of pre-releases (0.2.92-pre1, 0.2.92-pre2...). New features
> won't be added to this branch.
> 
> The main trunk remains the branch for experimental developments, and
> will, in time, become 0.3.0 and over. It will be branched every time
> a new stable release is planned (0.2.92, 0.2.93, etc.).
> 
> We think this scheme would simplify the development (no longer "stop
> adding new features, we're in release mode !") and make bug hunting
> more reliable (the stable branch won't change a lot).
> 
> Comments, etc.
> 
> [FYI this is inspired by what the PHP team has been forced to do in
> the 4.0.x releases]
> 
> --
> Christophe Massiot.