On 2013-01-03 01:58, Walter Bright wrote:
> As always, when I try to do a release, problems crop up. For example,
> the github procedure agreed upon and outlined here:

Don't know if this is the exact model we want to follow but here are some commands:

https://github.com/nvie/gitflow

These are based on "A successful Git branching model" that has been talked about before:

http://nvie.com/posts/a-successful-git-branching-model/

-- 
/Jacob Carlborg

Am Fri, 04 Jan 2013 07:59:05 +0100
schrieb "Rob T" <rob@ucora.com>:

> 
> I'm not certain what the major difference is between (1) and (2), because they both sound very nearly identical. In both cases, they seem to provide the same goals of stabilizing the next release, while allowing development to proceed unhindered, so if (2) can be made to achieve the goal I described for attracting real world beta testers, it may not matter which is used, however I would suggest that we always focus on serving the needs of the end user as a top priority as much as is possible. D requires plenty of significant end users working on significant projects.
> 
> You did mention that (1) is more suitable for beta testers, so I ask how is (2) not as suitable?
> 
> --rt

http://wiki.dlang.org/User:Jpf/Release_Process

I updated the page with some more git commands, ascii art and color so it's hopefully easier to understand now. Please tell me if I got anything wrong. The only thing I (intended to change) changed is that I removed staging.

Although I can see the benefits of staging as you describe it, we can get most of those by just creating a new release/version branch as soon as the current release is released. This removes some complexity from the workflow.

AFAIK it should be easy enough to introduce staging later on, when everyone is comfortable with the new workflow. (Please consider that many of us are not git experts - so if we can avoid some complexity now and add it later if needed, I'd prefer that)

Am Fri, 04 Jan 2013 12:02:44 +0100
schrieb "mist" <none@none.none>:

> Weird. While I was reading "Next focus: PROCESS" topic and http://wiki.dlang.org/Proposed_new_D_development_process entries, I was completely convinced that switch to faster release model is proposed, so that master replaces staging the very moment one version is released (and it is the same moment as testing of next release begins). Plus once a year or so release is marked LTS and cherry-pick bug-fixes until next LTS is out. Was my understanding wrong?
> 
> Anyway, now I am reading all those comments and it feels absurdly like no one has discussed this stuff few weeks ago and different topic and argument has started from beginning. This is madness.

So someone who was part of that discussion: Please give us a short summary. You can't expect everyone to read through all those posts again, 95% is probably obsolete.

And most important: Were the main developers part of that discussion / have they agreed? While I agree LTS would be nice it needs someone to do it. You also have to consider the available man power.

But this is not very relevant for this discussion: It's always possible to increase support time later.

On Thursday, 3 January 2013 at 00:59:04 UTC, Walter Bright wrote:
> As always, when I try to do a release, problems crop up. For example,
> the github procedure agreed upon and outlined here:
>
> http://wiki.dlang.org/Proposed_new_D_development_process#Release_a_new_version_of_D
>
> Issues:
>
> 1. you cannot have a tag and a branch with the same name. At least, you cannot push them with:
>
>     git push origin 2.N+1
>
> because it's ambiguous. So I prepended a v to the tag name.
>

Let's get a very practical case here. 2.061 have been released, and Kenji already fixed a bug in it (unreachable statement issue).

Some people (including me, but I'm not the only one) would be interested by a new revision of dmd with that fix.

It is why the proposal include branches as 2.N and revision as 2.N.M . So the same version of D, with bugfixes can be published.

The branch has a 2.N form, the tag has a 2.N.M form.

On Thursday, 3 January 2013 at 18:58:51 UTC, Walter Bright wrote:
> Turn that around - what's the benefit of keeping it? It's just clutter.
>

It has been discussed here before, and many people agreed that stagging can go away, as changes made in the proposal made it quite redundant. That sounds the reasonable thing to do.

Am Fri, 04 Jan 2013 15:55:01 +0100
schrieb "deadalnix" <deadalnix@gmail.com>:

> On Thursday, 3 January 2013 at 18:58:51 UTC, Walter Bright wrote:
> > Turn that around - what's the benefit of keeping it? It's just clutter.
> >
> 
> It has been discussed here before, and many people agreed that stagging can go away, as changes made in the proposal made it quite redundant. That sounds the reasonable thing to do.

I just thought about something - maybe staging isn't 100% redundant. I assume my conclusions on http://wiki.dlang.org/User:Jpf/Release_Process are correct:

If we want release stabilization time == time between 2 releases i.e. we start a new release/version branch after every major release:

Let's say 2.062 is in stabilization phase and we use the 2.062 branch.
Then bugfixes are based on / merged into 2.062 branch. So someone opens
a pull request targeting the 2.062 branch with a bugfix. For some
reason (lack of time) this request isn't merged till 2.062 is released.
After the release only regression fixes should go into 2.062.
But we now have a bugfix (not regression) pull request targeting the
2.062 branch!

Staging completely avoids that issue. So is this reason enough to have staging?

On Fri, Jan 04, 2013 at 03:00:10PM +0100, Johannes Pfau wrote:
> Am Fri, 04 Jan 2013 07:59:05 +0100
> schrieb "Rob T" <rob@ucora.com>:
> > 
> > I'm not certain what the major difference is between (1) and (2), because they both sound very nearly identical.

That's because they are essentially two ways of implementing the same concept.


> > In both cases, they seem to provide the same goals of stabilizing the next release, while allowing development to proceed unhindered, so if (2) can be made to achieve the goal I described for attracting real world beta testers, it may not matter which is used, however I would suggest that we always focus on serving the needs of the end user as a top priority as much as is possible. D requires plenty of significant end users working on significant projects.
> > 
> > You did mention that (1) is more suitable for beta testers, so I ask
> > how is (2) not as suitable?

I don't think the difference is that serious. (1) is just more _convenient_ for beta testers, because there's an actual branch called 'staging', so they just have to grab that. (2) requires that they know which version branch is the latest, which again, isn't that big of a deal.


[...]
> http://wiki.dlang.org/User:Jpf/Release_Process
> 
> I updated the page with some more git commands, ascii art and color so it's hopefully easier to understand now. Please tell me if I got anything wrong. The only thing I (intended to change) changed is that I removed staging.

I like what you did with the page. I think it makes it a lot clearer. I read through "Release Schedule" and "Branching model", and I think it pretty much captures what I described as approach (2).


> Although I can see the benefits of staging as you describe it, we can get most of those by just creating a new release/version branch as soon as the current release is released. This removes some complexity from the workflow.

If this approach is more suitable for the core devs, then I think we should go with it.


> AFAIK it should be easy enough to introduce staging later on, when everyone is comfortable with the new workflow. (Please consider that many of us are not git experts - so if we can avoid some complexity now and add it later if needed, I'd prefer that)

Whether or not one is a git expert ought not matter, if we define the process sufficiently clearly that one can simply look up the wiki page and type in the commands as-is, like a script, as Walter puts it. The important point is to agree on a single implementation of the process, and supply complete and unambiguous series of git commands to carry out the process.


T

-- 
The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis

On Friday, January 04, 2013 15:20:02 Johannes Pfau wrote:
> And most important: Were the main developers part of that discussion / have they agreed? While I agree LTS would be nice it needs someone to do it. You also have to consider the available man power.

For the most part, I don't think that they were. I think that Andrei was really the only one of us involved at all, though I'd have to look at the thread again to be sure.

- Jonathan M Davis

On Friday, January 04, 2013 15:26:20 deadalnix wrote:
> On Thursday, 3 January 2013 at 00:59:04 UTC, Walter Bright wrote:
> > As always, when I try to do a release, problems crop up. For
> > example,
> > the github procedure agreed upon and outlined here:
> > 
> > http://wiki.dlang.org/Proposed_new_D_development_process#Release_a_new_ver sion_of_D
> > 
> > Issues:
> > 
> > 1. you cannot have a tag and a branch with the same name. At
> > 
> > least, you cannot push them with:
> >     git push origin 2.N+1
> > 
> > because it's ambiguous. So I prepended a v to the tag name.
> 
> Let's get a very practical case here. 2.061 have been released, and Kenji already fixed a bug in it (unreachable statement issue).
> 
> Some people (including me, but I'm not the only one) would be interested by a new revision of dmd with that fix.
> 
> It is why the proposal include branches as 2.N and revision as 2.N.M . So the same version of D, with bugfixes can be published.
> 
> The branch has a 2.N form, the tag has a 2.N.M form.

And why would that particular bug get a release as opposed to another? Why wouldit be special? Or are you proposing that we do a 2.N.M release for every bug fix? That seems insane. Why wouldn't you just use master if you want the latest?

- Jonathan M Davis

On Fri, Jan 04, 2013 at 04:14:00PM +0100, Johannes Pfau wrote: [...]
> I just thought about something - maybe staging isn't 100% redundant. I assume my conclusions on http://wiki.dlang.org/User:Jpf/Release_Process are correct:
> 
> If we want release stabilization time == time between 2 releases i.e. we start a new release/version branch after every major release:
> 
> Let's say 2.062 is in stabilization phase and we use the 2.062 branch. Then bugfixes are based on / merged into 2.062 branch. So someone opens a pull request targeting the 2.062 branch with a bugfix. For some reason (lack of time) this request isn't merged till 2.062 is released.  After the release only regression fixes should go into 2.062.  But we now have a bugfix (not regression) pull request targeting the 2.062 branch!
> 
> Staging completely avoids that issue. So is this reason enough to have staging?

I'm not sure, but in my experience at my day jobs, any bugfix that *can* be applied to master (i.e., the code hasn't diverged so much that the fix doesn't apply anymore), *should* be. For this reason, it's best to always base bugfixes on master, unless the code has diverged so much the fix only applies to a particular release branch. Otherwise you end up with the problem somebody mentioned, that the bug is fixed in a previous release, but is "unfixed" in a later release because we neglected to merge the fix into master.

Of course, it's possible to base the fix on the release branch and merge it back to master, but the latter step is more prone to be forgotten. But then again, post-release regression fixes should probably be based on the release branch, so that we know that the fix works, as master may have diverged significantly since the original release branch was made. So either way, we have to make sure fixes are applied back to master.


T

-- 
May you live all the days of your life. -- Jonathan Swift