[asterisk-dev] [policy] Merging between branches

[Johansson Olle E]

1 dec 2008 kl. 14.57 skrev Russell Bryant:

> Greetings,
>
> Last year, when we first started discussing Asterisk 1.6 branch policy
> [1], we had said that the only time that we would change a 1.6.X  
> branch
> after it had reached a release state is for regressions against a
> previous release.
>
Russell,
Thanks for remembering to post this to the list before changing the  
policy.

I'm surprised to see no comments at all. I've gotten a lot of feedback  
off-list
on my recent attacks on the release policy.

For detailed response, I'm waiting for your promised writup. Right  
now, I'm too
confused on all different versions and the lack of what I would call a  
proper
trunk, a playground for new ideas and architectures. Maybe I'm just a  
kid
that needs my old Teddy Bear and can never get found of the new plastic
one... :-)

I personally think the current release schedule that touches the core  
between
1.6 releases is wrong. We should keep the core, but allow new modules
to flow in more quickly than we did in 1.4. This way, my customers would
get some stability in a 1.6 release somewhere along the line, resting
assured that the core functionality won't be changed, even though
new applications, functions and other modules with cool stuff are added.

Big changes, like kill-the-user and hash-tables and stuff that really
changes the internals should be in a trunk where we can spend a lot
of time with the big core changes without going into beta as quickly
as we have done now. Merging kill-the-user to trunk was wrong,
considering it quickly became part of 1.6.1 beta. On the other hand,
no one really tests branches. We need a common next-generation
branch (like the old trunk) where developers can test this kind of large
changes in a combined code base.

And if you want non-full-time coders to participate, please keep
it simple.

Executive summary:
  - Protect the released core functionality. Only accept bug fixes
    and module add-ons that won't affect core functionality.
- Re-create a trunk for the next generation release
- Keep it simple

/O