On 04/29/12 23:55, Juergen Schmidt wrote:
...
I think it all depends on how fast we plan to release 4.0.
It looks likely that merging Symophony may be easy for the
IBM guys, since symphony already updated theit base OOo,
so a release may be fast and the 3.x branch may be short
lived. (I don't know for sure though).
One thing here that I should've mentioned is that it's rather
inconvenient that we will not have the symphony history. It
would've made it much easier to merge features.
I think a 3.x branch does make sense in any case but the
rule should be clear: no direct commits to the stable
branch: in general all changes go first to the trunk
and are later merged.
I don't think so, I would do it exactly in the other direction. Fixes
for critical issues or issues that are assigned for a 3.4.1 should be
fixed on the related stable branch and also merged into trunk.
Well, developing an OS is different than developing an Office
Suite but direct commits to the stable branch in my favorite
OSS project are prohibited except for specific cases (like if
the code disappeared from trunk already) for good reasons.
For one thing we are many committers and it's easy to lose track
if the change was merged to the trunk so it is a good policy to
ensure consistency in the different versions. It also keeps
the SVN merge properties consistent. I am by no means
a SVN expert but it's likely that using "svn merge", instead of
"svn commit" in branches is the recommended practice.
Just my $0.02,
Pedro.
