[vlc-devel] The case for 2.0

[Rémi Denis-Courmont]

Le dimanche 8 janvier 2012 02:15:48 Pierre Ynard, vous avez écrit :
> So now we're not talking about just the next release, but all majors
> releases from now on. Will all following releases bring as many features
> as Twoflower, and be way beyond and different from the previous one, and
> feature a license change, to warrant the same number bump?

The current development process has three levels of release (major releases, 
bugfix releases and repackaging), yet the versioning scheme has four (major 
number, minor number, revision number and optional packaging letter). This is 
inconsistent, and that is why this is not the first time we debate whether to 
increment the major version or the minor one.

Unless someone has a better idea on how to use the major version number, I 
think it would make sense to use it for stable branches / major release / 
whatever-you-want-to-call-them.

(...)
> Rather than trying to pin landmarks on an empty timeline, it would be
> better to plan what big features we want in the next version. The fact
> that this an opensource project driven by volunteers doesn't mean that
> we can't at least try to do this.

Feature-based versus time-based. The project history suggests that feature-
based releases simply don't work because there is not enough commitment to 
finishing features, and time-based releases don't work because there is not 
enough commitment to stabilizing branches.

So unless one of you turns into a VLCtropic billionaire, this is screwed 
either way.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis