Next focus: PROCESS

[foobar]

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.