Next focus: PROCESS

[RenatoUtsch]

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