On Wednesday, 12 December 2012 at 10:22:32 UTC, foobar wrote:
To summarize:
2. The version scheme is meaningless. Please check out
http://www.mozilla.org/en-US/firefox/channel/#firefox as an
example. It's perfectly clear, you can choose what Mozilla
calls a channel - i.e "release" or "beta".
I agree Firefox has a meaningless version numbering system
because Firefox adopted a meaningless version numbering system. I
don't understand the rational behind the decision to switch from
the previous one that was meaningful.
What advantage do you gain by dropping a major, minor, and
revision from your version numbering system?
We can put both in a two column table with high-level
description of changes and links to more-detailed change logs.
There's no harm in doing that, but what would be most useful is
knowing if the change is a major one or a minor one or just for
bug fixes.
3. Debian is a HUGE project with lots of manpower. D is not.
We all know this, but that does not mean we cannot do a lot
better than we're doing now, and if we can get rid of the waste,
like those endless debates that cannot be resolved with one
branch, then there'll effectively be more manpower available.
I think it is enough to have two _publicly visible download
channels_ - release and beta (testing). Those are the only two
that should be formally defined. There is no need to define
prior stages of development as people can just informally
create their own local branches for their own experiments and
they could also push them upstream to share with other
developers without any requirement to list an executable on the
official download page. The source code is available on github
- if you wanted to you could pull whatever branch and build it
yourself at your own risk.
But that's almost what we have now, and it does not work and it
never will work.
The problem with only two official branches, is that one has to
be for a stable version, and the other has to be for the "new
stuff", but there's two kinds of "new stuff". One kind is for
breaking changes, or for introducing new concepts that have not
been well tested. and the other kind is for field testing new
concepts that are reasonably well understood and cause no
breaking changes.
What real-world programmers want to have, is a reasonably stable
"beta" version that they can use for real work - this is NOT for
playing around with, but for making things work for real. They
want the beta because it has something that the stable does not
yet have.
What these guys don't want, and cannot put up with for real world
programming, is an unstable alpha, but that's what you are
proposing we continue on with, which is exactly what we have now
and it does not work.
In addition, once the beta/alpha is close to ready to be released
into stable, it has to be frozen for a few months, where no new
features are added and only bug fixes continue on, but then
you've just lost your unstable branch!
Have a look at the thread on the introduction of UDA's to see
what's going on, and ask yourself if a two branch system will
solve that kind of never ending problem.
4. The only official executables on the download page are for
two channels - release and beta. You can grab the latest stable
"release" that only gets critical bug-fixes or the monthly beta
that also contains preview features such as the upcoming
user-defined attributes. You can also grab previous versions of
both release channels by clicking the "previous versions" link.
Anything else has zero guaranties and you are required to build
yourself from source.
That all works fine. What I think is glaringly missing is the
unstable branch, so we need at a minimum 3 branches.
--rt
