December 14, 2012
On 12/14/12 10:02 AM, H. S. Teoh wrote:
> A number of us have put up a draft of a proposed release process on the
> wiki, based on some of the things discussed in this thread.
>
> 	http://wiki.dlang.org/Release_Process

Seen it, will give a thorough read today. Thanks!

Andrei
December 14, 2012
From the discussion there appears to be more that believe that master should remain the development branch.

From this, 'staging' is seen as the branch to prepare a release from (bug fix only).

We are currently in the 2.61 freeze, let us move this freeze to the staging branch now!

Any disagreement with this? Does anyone see this changing as we continue to work out the flow? All I can see is bikeshedding the name.
December 14, 2012
On Friday, 14 December 2012 at 15:36:05 UTC, Jesse Phillips wrote:
> From the discussion there appears to be more that believe that master should remain the development branch.
>
> From this, 'staging' is seen as the branch to prepare a release from (bug fix only).
>
> We are currently in the 2.61 freeze, let us move this freeze to the staging branch now!
> Any disagreement with this? Does anyone see this changing as we continue to work out the flow? All I can see is bikeshedding the name.

Yes, we could use 2.61 as the first trial to get things moving along, even if it's not 100% ready and agreed on, it seems obvious that we'll want to use a "staging branch" to work out the bugs while in freeze - I don't think anyone is seriously objecting to that, right?

However here's a cautionary note: I read that Walter has specific motives right now concerning a timely release for a strategic D user that can help move D into a more prominent position, so if we're to support a release as smoothly as possible, I wonder if now is or is not the time to try this out on 2.61?

My gut says, "of course go for it", because I can't see how anything could get worse instead of better by doing so, however just mentioning that this release is an important one to carefully consider.

BTW, the wiki page is looking very good guys. Well done!!!

--rt
December 14, 2012
On Friday, 14 December 2012 at 17:17:16 UTC, Rob T wrote:
> However here's a cautionary note: I read that Walter has specific motives right now concerning a timely release for a strategic D user that can help move D into a more prominent position, so if we're to support a release as smoothly as possible, I wonder if now is or is not the time to try this out on 2.61?

I thought on this and believe it is a good time to make 2.61 stable. Especially with Walter wanting to keep the feature (syntax) in just for them. They can trust it will remain a warning for x years.

But let us do this for a shorter than planned stable. This will allow us to try out the new process, and be no worse off than before.

But let us first get this branch. Ignoring how long this release will last we should all be agreeable on continuing development in master and fixing release bugs in 'staging'
December 14, 2012
On Fri, Dec 14, 2012 at 06:17:15PM +0100, Rob T wrote: [...]
> BTW, the wiki page is looking very good guys. Well done!!!
[...]

Thanks, but we do still have issues to work out, details to fill in, etc.. We'd love to have your input too!


T

-- 
We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare.  Now, thanks to the Internet, we know this is not true. -- Robert Wilensk
December 14, 2012
On Friday, 14 December 2012 at 19:01:23 UTC, H. S. Teoh wrote:
> On Fri, Dec 14, 2012 at 06:17:15PM +0100, Rob T wrote:
> [...]
>> BTW, the wiki page is looking very good guys. Well done!!!
> [...]
>
> Thanks, but we do still have issues to work out, details to fill in,
> etc.. We'd love to have your input too!
>
>
> T

Yes very true, long ways to go yet. I will try and continue contributing! To me, all things considered, this is THE most important issue limiting the growth and adoption of D because absolutely everything else depends on it running smoothly.

--rt
December 14, 2012
12/14/2012 4:12 PM, Manu пишет:
> One thing that I think would be really awesome when this is all rolling,
> is attach a system that does nightly builds of the dev line every evening.
> I've often had to pester Walter to produce a new build for us when a
> critical bug/feature was fixed.

Then this could be of interest:

http://forum.dlang.org/post/mailman.2633.1355345752.5162.digitalmars-d@puremagic.com

From that I take it's basically coming soon.

-- 
Dmitry Olshansky
December 15, 2012
12/14/2012 3:34 AM, deadalnix пишет:
> On Thursday, 13 December 2012 at 20:48:30 UTC, deadalnix wrote:
>> On Thursday, 13 December 2012 at 20:04:50 UTC, Dmitry Olshansky wrote:
>>> I think it's good.
>>>
>>> But personally I'd expect:
>>>
>>> * master to be what you define as dev, because e.g. GitHub puts
>>> master as default target branch when making pull requests. Yeah, I
>>> know it's their quirk that it's easy to miss. Still leaving less
>>> burden to check the branch label for both reviewers and pull authors
>>> is a net gain.
>>>
>>> * And what you describe as master (it's a snapshot or a pre-release
>>> to me) to be named e.g. staging.
>>>
>>> And we can as well drop the dead branch 'dev' then.
>>
>> That sound also like a good plan to me.
>
> Updated to follow the idea, plus added bunch of process description.
> Feel free to comment in order to refine this.
>
> http://wiki.dlang.org/Release_Process

I wasn't comfortable doing speculative edits to the wiki directly so here a few more comments:

I think one of major goals is to be able to continue ongoing development while at the _same time_ preparing a release. To me number one problem is condensed in the statement "we are going to release do not merge anything but regressions" the process should sidestep this "lock-based" work-flow. Could be useful to add something along these line to goals section. (i.e. the speed and smoothness is a goal)

Second point is about merging master into staging - why not just rewrite it with master branch altogether after each release?
master is the branch with correct history (all new stuff is rebased on it) thus new staging will have that too.

-- 
Dmitry Olshansky
December 15, 2012
On Saturday, 15 December 2012 at 10:29:55 UTC, Dmitry Olshansky
wrote:
> 12/14/2012 3:34 AM, deadalnix пишет:
>> On Thursday, 13 December 2012 at 20:48:30 UTC, deadalnix wrote:
>>> On Thursday, 13 December 2012 at 20:04:50 UTC, Dmitry Olshansky wrote:
>>>> I think it's good.
>>>>
>>>> But personally I'd expect:
>>>>
>>>> * master to be what you define as dev, because e.g. GitHub puts
>>>> master as default target branch when making pull requests. Yeah, I
>>>> know it's their quirk that it's easy to miss. Still leaving less
>>>> burden to check the branch label for both reviewers and pull authors
>>>> is a net gain.
>>>>
>>>> * And what you describe as master (it's a snapshot or a pre-release
>>>> to me) to be named e.g. staging.
>>>>
>>>> And we can as well drop the dead branch 'dev' then.
>>>
>>> That sound also like a good plan to me.
>>
>> Updated to follow the idea, plus added bunch of process description.
>> Feel free to comment in order to refine this.
>>
>> http://wiki.dlang.org/Release_Process
>
> I wasn't comfortable doing speculative edits to the wiki directly so here a few more comments:
>
> I think one of major goals is to be able to continue ongoing development while at the _same time_ preparing a release. To me number one problem is condensed in the statement "we are going to release do not merge anything but regressions" the process should sidestep this "lock-based" work-flow. Could be useful to add something along these line to goals section. (i.e. the speed and smoothness is a goal)
>
> Second point is about merging master into staging - why not just rewrite it with master branch altogether after each release?
> master is the branch with correct history (all new stuff is rebased on it) thus new staging will have that too.

Here what I proposed on the discussion page, what do you think?

------------------
I have come with a good idea for the release schedule. Say that
we are 3 or 4 monthes before the next LTS release. We need to
branch the staging branch in a 2.N (put the contents of the
staging branch in the 2.N branch) branch, where N is the new LTS
version. Then, no other features can be included in this 2.N
branch, only bugfixes are allowed. This period will have one RC
every month (?) with the latest fixes in the 2.N branch. After
the 3 or 4 monthes period we'll tag the 2.N.0 release. After
every 4~6 monthes, we'll release a new 2.N.x version with the
latest bugfixes in the 2.N branch, but with no additional
features (including non-breaking features here will just be more
work to the devs, I don't think it is a good idea). While these
bugfix releases are being made, every feature that stabilizes
enough in the master branch is merged into the staging branch,
where the feature shouldn't have much breaking changes (although
changes are still allowed, the branch is not frozen). Every 3
monthes, dev releases are made with these features that made
their way into the staging branch. This is done while the fixes
in the 2.N branch are made. Then, 4 monthes prior to the next LTS
release, a new 2.N+1 branch will be created with the staging
branch contents. The cycle will repeat, these 4 monthes will have
no additional features on the 2.N+1 branch, and neither on the
next 3 years. This organization, in dev and LTS releases, will
allow releases for the ones that want a stable environment to
develop (the LTS releases) and the ones that want the latest
great features from D will have a somewhat stable environment
(the dev releases, somewhat like the ones we have now, maybe a
little more stable) to use. On top of that, the staging branch
will never be frozen, so development will never stop, as someone
was saying on the forums that was a bad idea. And, when the new
LTS release is made (2 years after the older LTS), the older LTS
will be mantained for more one year, what means that each LTS
will be mantained for 3 years. What do you think? RenatoUtsch
(talk) 14:14, 15 December 2012 (CET)
------------------
http://wiki.dlang.org/Talk:Release_Process#Expanding_LTS
December 15, 2012
On 12/15/2012 2:29 AM, Dmitry Olshansky wrote:

> I think one of major goals is to be able to continue ongoing development while at the _same time_ preparing a release. To me number one problem is condensed in the statement "we are going to release do not merge anything but regressions" the process should sidestep this "lock-based" work-flow. Could be useful to add something along these line to goals section. (i.e. the speed and smoothness is a goal)

I've been staying out of this thread for the most part, but I feel the need to comment on this part specifically.  It's quite common for most major projects to have a clear "we're wrapping up a release" phase where work _is_ restricted to bug fixing and stabilizing.  They don't stop people from working off in their development branches (no one could effectively impose such restrictions even if they wanted to), but they _do_ tighten down on what's allowed to be merged.

This is a forcing function that's just required.  There's a lot of issues that otherwise won't get sufficient attention.
 If all it took was altruism then regressions would be fixed immediately, bugs would always be fixed in highest priority
to lowest priority (assuming that could even be effectively designed), etc.

Without the 'ok, guys, focus in this smaller more critical subset of bugs' step, release branches would be created and never polished (or focused down to the release manager to do all the work if he's that skilled and/or generous of his time).

There's a phrase I'm trying to remember, but it's something to the effect that 'hope isn't a recipe for success.' Hoping that people fix regressions on release critical bugs isn't sufficient.  Incentive and steering is required.  The desire to ungate master branch merges is one approach that's been shown to be successful.