Agree with Shelley's points, which go beyond the issue of 1.2 vs. 2.0. A roadmap with a target date for a 3.0 is definitely a marketing tool that provides an advantage to VLC beyond its quality and availability.<div><br>
</div><div>From a user perspective, a license change in and of itself would warrant a major version number. This affects not just how programmers interact with the product but also (potentially) the users themselves.</div>
<div><br></div><div>I would also like to suggest adoption of a numbering system similar to the Linux kernel, to avoid the "pre-" and ".99" and such in the versions. Even-numbered minors are development branches; odd minors are released. Thus, the current development (Twoflowers) is 2.0, and when it's released it's 2.1. Rincewind would be 2.2, and the released version 2.3. (Or 3.0 and 3.1 if need be. On a side note, I generally associate new names, like Rincewind, with a major-version bump -- compare Ubuntu, Fedora, etc.) This has the advantage of never releasing ".0" versions, which as I have advised my clients in the past, should be avoided like the plague. :-)</div>
<div><br></div><div> <br><br><div class="gmail_quote">On Sun, Jan 8, 2012 at 5:27 AM,  <span dir="ltr"><<a href="mailto:vlc-devel-request@videolan.org">vlc-devel-request@videolan.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Message: 5<br>
Date: Sat, 7 Jan 2012 17:15:39 -0800 (PST)<br>
From: Shelley Horwitz <<a href="mailto:shelley@sjcomm.com">shelley@sjcomm.com</a>><br>
To: "<a href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a>" <<a href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a>><br>
Subject: Re: [vlc-devel] The case for 2.0<br>
Message-ID:<br>
        <<a href="mailto:1325985339.50472.YahooMailNeo@web83701.mail.sp1.yahoo.com">1325985339.50472.YahooMailNeo@web83701.mail.sp1.yahoo.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
The reason for changing version numbers is as much a Marketing decision as it is for features and functions. When versions do not change for a very long time, users do not perceive any improvement in the product itself and look for other "more modern" tools with better technology.<br>

<br>
<br>
A good guideline for new versions is once every year. Some products go every six months, some go every 1 1/2 years. A schedule of updates every quarter, and a major release each year gives your users the idea that the development team has a plan. The length of time is not as important as consistency in updating and upgrading on a reasonable schedule. This is a good example of a professional development environment, rather than a bunch of hackers tinkering with a new toy.<br>

<br>
<br>
Having such a schedule shows that you have a roadmap for developing your software; it gives your users confidence that this product has a future they can depend on. Continuous release of subversions only to fix problems does exactly the reverse. It indicates that the program is going nowhere and even after a long life, still has problems.<br>

<br>
This issue is about your customers PERCEPTION of the quality and longevity of VLC; it is not about how much or how little changes. It is what your users see about the future of VLC. It is what they believe, not about what you change.<br>

<br>
It is time for VLC 2.0. It is time to start planning for all future releases and updates for VLC. It is time to set goals and targets. It is time to develop a ROADMAP!!! It is time to show both your users and your developers that VLC has a future.<br>

<br>
<br>
<br></blockquote></div></div>