On Sat, 1 Jul 2006, Ulf Lamping wrote:
> Kukosa, Tomas wrote:
> > Would not it be better to make /trunk-1.0 as late as we have implemented all features planned for 1.0.0?
> > Then the /trunk-1.0 would continue only with bug fixies.
> >
> > I am affraid when we make /trunk-1.0 now we will come to the same conclusion during next release, i.e. to forgot /trunk-1.0 and use /trunk.
> >
> I had a similar feeling.
>
> Looking at the way the story went: the work of copying over from the
> experimental to the stable branch was an overhead that caused a lot of
> confusion and unpleasant work.
>
> So in my eyes it was a try that failed. However, doing the same mistake
> again would be dumb, as I don't see any reason that it will work the
> next time.
>
> The purpose of the stable branch was to raise the quality of the release.
>
> We might take other mechanisms:
> - a zero compiler warning tolerance (difficult as we compile on several
> different platforms)
> - a requirement to provide capture files (for fuzz-testing)
> - release more often (to provide at least fixes for the known and
> currently fixed bugs)
> - don't accept substantial changes near release time (no new dissectors,
> ...)
>
> I know that the "renaming session" took a lot of recent effort, but I
> think the former method of simply release often did a better job than
> the current "splitted branches" solution.
>
> Regards, ULFL
FULL ACK.
Having a develoment trunk and release branches just take more management
around the time of the branch. Calm down on the new stuff, focus on
bugfixes then branch and work only on the stability of the branch. Have a
look at the Linux kernel development process, they face the same problems.
Thanx,
Jaap