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
