View mode: basic / threaded / horizontal-split · Log in · Help
December 12, 2012
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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.
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home