View mode: basic / threaded / horizontal-split · Log in · Help
January 04, 2013
Re: github release procedure
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
January 04, 2013
Re: github release procedure
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)
January 04, 2013
Re: github release procedure
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.
January 04, 2013
Re: github release procedure
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.
January 04, 2013
Re: github release procedure
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.
January 04, 2013
Re: github release procedure
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?
January 04, 2013
Re: github release procedure
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
January 04, 2013
Re: github release procedure
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
January 04, 2013
Re: github release procedure
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
January 04, 2013
Re: github release procedure
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
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home