On Wednesday, 12 December 2012 at 18:25:10 UTC, Rob T wrote:
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
I really didn't want to get dragged into the versioning scheme
debate as it is just bikesheding in disguise but oh well.. I'll
ask in return, what's the added benefit of your scheme? I
honestly see no added benefit whatsoever.
There's no intrinsic benefit compared to a changelog that lists
"Jelly bean" after "Ice cream sandwich". How do you know what was
added to a version? Simple, you have a "what's new" page that
lists new major features denoted by "New feature:" tag and
bug-fixes denoted by "Bug-Fix:" tag.
Here's an example -
http://www.mozilla.org/en-US/firefox/17.0.1/releasenotes/
Regarding the important (IMO) part of the discussion - 2 vs. 3
levels - I feel I haven't explained myself properly so let me
clarify:
I was taking into account what I thought was a reasonable
assumption that D2 is in the process of stabilization and no
major redesigns are planed. This means the "Major" version is 2
as in D2.
My stable releases are meant to be the "Minor" releases on the D2
branch. These releases can introduce new backwards-compatible
features and restricted breaking changes when absolutely required
_over several releases_ with _a well defined migration(*)
process_ - in other words support evolution.
Major redesigns belong under a "revolution" such as the python3
effort. There is no point on setting time-lines for that. If and
when we accumulate enough reasons/momentum/etc for such a major
break we'll just create a new "major" version of D called D3
which right now is completely off the table.
This is _not_ exactly what we have now because now new features
are introduced right away, without public field testing (the beta
channel). We have no defined criteria as to when a feature is
mature enough to have it's syntax/API frozen and should be
graduated from beta phase and integrated into stable. That is the
point of defining the process.
(*) A well defined migration path should span several stable
versions and define these stages:
1. Warn the user that a feature is going away/ is going to be
changed
2. Deprecate the feature and don't accept it at compilation
(unless -d is used)
3. remove the feature completely.
