December 12, 2012
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
December 12, 2012
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".

This is a poor example as it doesn't show how the development team develops these versions.

If we are going to have a branch supported separate from the beta/dev builds then we need a way to say that this stable version is newer but is not as new as the beta/dev.

If we release 2.61 as a stable, we would then develop new features in which version? 2.62 beta 1? If so, when we release 2.61 with a bug fix which version do we release? 2.62? 2.61 stable 2?

You are right that version numbers have absolutely no meaning, I don't remember if it was you, but they are also not as important as the process improvements. However if we assign meaning to numbers there can be benefit. Mozilla basically just did away with the Major version. (I say we do a Linux and leave the 2 then realize it has no meaning and up it to 3 when we reach the age of the 2.0 kernel)

We should combine your beta with an added version number.

2.61.0 => bugfixes => 2.61.1
2.61.0 => newfeatures => 2.62.0 beta 1
2.62 => preparing for stabilizing => 2.62 rc1

just some thoughts.
December 12, 2012
On Wednesday, 12 December 2012 at 18:04:43 UTC, Joseph Rushton Wakeling wrote:
> People have talked about Debian's unstable => testing => stable model, but instead, why not consider something more akin to Ubuntu's LTS and interim releases?


No, no, please. As already stated, distro release systems intend to solve the exact opposite problem of ours. If you want to look at what is done in the field, look at other programming languages.
December 12, 2012
On Wednesday, 12 December 2012 at 18:33:17 UTC, Jesse Phillips wrote:
> If we release 2.61 as a stable, we would then develop new features in which version? 2.62 beta 1? If so, when we release 2.61 with a bug fix which version do we release? 2.62? 2.61 stable 2?
>
> You are right that version numbers have absolutely no meaning, I don't remember if it was you, but they are also not as important as the process improvements. However if we assign meaning to numbers there can be benefit. Mozilla basically just did away with the Major version. (I say we do a Linux and leave the 2 then realize it has no meaning and up it to 3 when we reach the age of the 2.0 kernel)
>
> We should combine your beta with an added version number.

The beta foobar speaks of is actually a combined alpha+beta, and that'll cause lots of problems and also delay releases because the combined alpha+beta will have to be frozen at some point prior to release as the next stable (i.e., frozen from enhancements that are not bug fixes only). Freezing the alpha+beta combo is not a problem for the beta portion, but it is a problem for the alpha portion that has no requirement to be frozen. You could just branch off the beta from the alpha into a special frozen branch, but then what are you doing? It makes no sense. Also important is that fact that there will be many programmers who could not wait for the next stable release and want to use the latest beta, but there is none, there's only and alpha+beta combo, and that'll mean the current problem we have right now will not be resolved where newly introduced features mess up the beta portion that people want to be able to rely on for real-world programming. The separation of alpha and beta allows for a beta that is at least far more stable than an alpha-beta combo, and that will satisfy the people who wish to move past the stable release into a beta, but wish to avoid the alpha entirely.

> 2.61.0 => bugfixes => 2.61.1
> 2.61.0 => newfeatures => 2.62.0 beta 1
> 2.62 => preparing for stabilizing => 2.62 rc1
>
> just some thoughts.

A 3 point numbering system used to differentiate between the stable bug fix releases and the beta version works just fine, and there's no need to introduce descriptive symbols, although that can be useful to indicate what is stable, beta or alpha.

In any event, I fully agree that the process is the most important item to work out first and foremost. When I mentioned version numbers, I simply wanted to remind people that it should also be on the table for change AND should be included into the process at some point to make it a well understood concept as opposed to what we have now. The response I got from Foobar was very surprising to me which is why I explored it further.

As was suggested in another post, I'll do a little digging to see what is going on with the development cycle of other programming languages. Best not to try and reinvent the wheel if we can. One thing about D is that I suspect there's a sizable faction that does not wish to do what other programming languages are doing, and that's to avoid introducing breaking changes completely. Personally I'd rather see flawed concepts get fixed at some point rather than have to live with them forever, the point being that we may be somewhat unique with our development process requirements.

--rt
December 12, 2012
On Wednesday, 12 December 2012 at 18:47:58 UTC, deadalnix wrote:
> On Wednesday, 12 December 2012 at 18:04:43 UTC, Joseph Rushton Wakeling wrote:
>> People have talked about Debian's unstable => testing => stable model, but instead, why not consider something more akin to Ubuntu's LTS and interim releases?
>
>
> No, no, please. As already stated, distro release systems intend to solve the exact opposite problem of ours. If you want to look at what is done in the field, look at other programming languages.

Point taken. Do you have any links or further info to offer on this line of thinking? I'd like to investigate, so a starting point would be nice to have if you can offer one up. Thanks!

--rt
December 12, 2012
On Wednesday, 12 December 2012 at 19:33:00 UTC, Rob T wrote:
> On Wednesday, 12 December 2012 at 18:47:58 UTC, deadalnix wrote:
>> On Wednesday, 12 December 2012 at 18:04:43 UTC, Joseph Rushton Wakeling wrote:
>>> People have talked about Debian's unstable => testing => stable model, but instead, why not consider something more akin to Ubuntu's LTS and interim releases?
>>
>>
>> No, no, please. As already stated, distro release systems intend to solve the exact opposite problem of ours. If you want to look at what is done in the field, look at other programming languages.
>
> Point taken. Do you have any links or further info to offer on this line of thinking? I'd like to investigate, so a starting point would be nice to have if you can offer one up. Thanks!
>

I did earlier, but let me repeat myself.

Distro rely on many program, that they intend to integrate.
Programming language rely on almost nothing but many programs rely on them.

The problems you have to solve are the exact opposite of one another.

I suggest considering how things are done in python, java, PHP or other successful languages.
December 12, 2012
Let me do some proposal. If people are happy with them, I can start some wikification.

First here are the branch already existing :

dev : development branch. It is used to merge new features.
master : is the branch where the next version is stabilized (right now, 2.061). It receive only bug fix. eventually new features if the feature is of strategic importance.
2.60 : contains the current released version of D + bug fix.

Release process :

When branch 2.60 have enoug bug fixes to justify a new release, a tag is created (2.60.N+1). The amount and the importance of corrected bugs will dictate when the release is done?

When master is stabilized enough, a new version of D can be released. A new branch s created from master, named 2.61 and a tag 2.61.0 is created :

git checkout master
git branch 2.61
git checkout 2.61
git tag 2.61.0

Then, the dev version is merged into master and a new stabilization process begin :
git checkout master
git merge dev

At some point, 2.60 will not receive any more bug fix, and will be considered very stable, or dead, depending on one's standard (both are kind of the same).

I advice against maintaining a log of 2.XXX branches, as too much choice is as bad as no choice for the user, and it is no better for us. 2 is IMO the right amount.

NB: I have chosen the 3 number system for branches names, this is up to debate, but as it is widely used in programming languages it is a good base. Anyway, let's not debate the name for too long, as it really don't matter, and concentrate on the workflow.

On Wednesday, 12 December 2012 at 16:14:44 UTC, Andrei Alexandrescu wrote:
> Beyond that we need to have a wiki page with workflows:
>
> "To initiate a new feature"
>

A new feature is developed in its own branch. The reference is the dev branch. In git it goes as follow :

git checkout dev
git branch featureName

Development of the feature.

You can work on many feature at the same time; each one in its own branch. You initiate them the same way and switch from one another with git checkout.

Before submitting a feature, it has to be reabsed as follow :

git checkout featureName
git rebase dev

When the feature is ready to inclusion into dev, the dev can make a pull request.

> "To initiate a bug fix"
>

The same as for new feature, except that you start from the branch the bug is in. If the bug is in several branches, then the most stable one is choosen, as i is usually easier to bubble up the bugfix from a stable branch to dev than the other way around.

> "To initiate a library addition without formal review"
>
> "To initiate a library addition with formal review"
>
> ...
>

I don't really know what to do here. I guess bug fixes on the library can be done the same way, but something specific probably have to be done with new modules.

> All of these should be subsections in the documentation.
>
> "If your branch has conflicts"
>

If your branch has conflict, it is up to you to resolve them. The conflict will most likely occurs when rebasing. In such case, git status will inform you on which files are impacted. Edit the file to resolve the conflict and do git add file, then git rebase --continue .

If you don't want to resolve the conflict now, you can abort the rebase by doing git rebase --abort

> "If your branch became really messed up"
>

Well this one is difficult, because it is unclear what is wrong, so unclear ho to solve it.

Is that good ?
December 12, 2012
On Wednesday, 12 December 2012 at 18:04:43 UTC, Joseph Rushton Wakeling wrote:
> It seems to me that while process is clearly very important, what's maybe necessary first is to identify what the actual results of the process are intended to be.  What should a 'stable version' of D actually mean, in practice?
>  What should its lifetime be?  Should there be interim releases in-between stable versions which can introduce e.g. breaking features, and should those be treated only as beta versions or as releases in their own right?  How is that coupled (or decoupled) from releases of the library? etc.
>
> I'd personally rather get those issues addressed out before talking about git methods, which to be honest I suspect will be similar no matter what the release model.
>

Agreed 100%. We're going about this completely ass backwards.

Here's my stab at defining the main points to achieve:

1) We want improved stability and predictability with compiler releases to prevent a new release from unexpectedly breaking existing D code without significant prior warnings and time to prepare for it.

2) Stable releases should remain stable while being maintained, which means "bug fixes only".

3) We don't want to cast the language in stone, so new features must be allowed to be introduced in a more predictable and planned way that allows D programmers to confidently use the new features in their production code.

4) We want to allow D to continue to be enhanced in a way that allows the D compiler developers to do what they do best, while not interfering with the growing D user base who wish to rely on relative stability and predictability.

Points 3 and 4 may seem the same, but the important difference is that there are two types of D users, those who use the language and those who develop the language and compiler (a person may do both of course), so the goals and requirements for each group of user are different and may conflict.

If I write stuff like this in here, it'll just end up disappearing into the black hole.

Can we agree to create a wiki page for defining what the main goals are, and what we wish to achieve?

Once we have consensus on what is to be achieved, we can define a process and test it to see if it will achieve what we want.

This is a much better approach than trying to build a process to achieve something that is not yet defined and agreed on.

--rt
December 12, 2012
On Wednesday, 12 December 2012 at 21:17:31 UTC, Rob T wrote:

> Can we agree to create a wiki page for defining what the main goals are, and what we wish to achieve?

I agree with the listed points.
December 12, 2012
On Wed, Dec 12, 2012 at 10:17:30PM +0100, Rob T wrote: [...]
> If I write stuff like this in here, it'll just end up disappearing into the black hole.
> 
> Can we agree to create a wiki page for defining what the main goals are, and what we wish to achieve?
> 
> Once we have consensus on what is to be achieved, we can define a process and test it to see if it will achieve what we want.
> 
> This is a much better approach than trying to build a process to achieve something that is not yet defined and agreed on.
[...]

Please let's use the new wiki at wiki.dlang.org to coordinate this effort. We don't want this discussion to vanish into the ether after 2 months, and we end up back at square one.


T

-- 
There are two ways to write error-free programs; only the third one works.