> The problem is that the user will use the latest trunk > of openocd. They do not know if this is a stable version or > in development. But they assumed to use it with the "old" > functionality.
We must use trunk to coordinate development and introduce stable branches for latest recommended version if need be. Possibly with backporting fixes. The daemon_startup removal work is not yet complete. To develop in branches is a non-starter because work won't get synchronized, we won't get feedback and the whole development process will stall. To never commit things in progress simply doesn't match the resources we have available for the project. The time may have come to start cutting stable branches. I've outlined the approach earlier, but it requires someone to watch over the stable branches. Also, Spen is in the process of taking over administration of the openocd web site where we can explain how the development process works(including where to find stable versions). Note that every version in subversion *is* a branch, so we don't need to cut a branch *before* we want to make it stable. We go back in time and figure out which version was the most stable and cut the stable branch from there. Cutting a branch has two purposes: it documents what code is considered stable and it allows backport of fixes. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
