[vlc-devel] The case for 2.0

[John Freed]

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.

>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.

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. :-)



On Sun, Jan 8, 2012 at 5:27 AM, <vlc-devel-request at videolan.org> wrote:
>
>
> Message: 5
> Date: Sat, 7 Jan 2012 17:15:39 -0800 (PST)
> From: Shelley Horwitz <shelley at sjcomm.com>
> To: "vlc-devel at videolan.org" <vlc-devel at videolan.org>
> Subject: Re: [vlc-devel] The case for 2.0
> Message-ID:
>        <1325985339.50472.YahooMailNeo at web83701.mail.sp1.yahoo.com>
> Content-Type: text/plain; charset="us-ascii"
>
> 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.
>
>
> 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.
>
>
> 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.
>
> 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.
>
> 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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120108/01d4fb83/attachment.html>