Next focus: PROCESS

[Rob T]

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