Hi all, This message tries to cover a proposal for a tactical release "process" for the OpenOCD community to consider. If there seems to be agreement that this will be acceptable, I will write start some the relevant bits up in a document and add it to the reference manual.
At the moment, we are continuing to apply outstanding work and bug fixes as we move to close the merge window, which I would like to have occur by the end of this week. With that in mind, I would like to plan to branch 0.2.0 as soon as possible. That means we need to wrap up everything that is either done, or choose to postpone it; the last message about features Essentially, I want us to cut a release with what we have and plan to repeat the process again repeatedly in the following weeks. Right now, the project has taken too much time since the last release to ensure that the set of supported targets will be a strict superset of those from 0.1.0. I think we must expect some things will be broken, and we will not find out what until we produce a new release for users to test. To prevent future regressions, I have started prototyping test result reporting tools that will allow users to report success or failures with their specific configurations. For simplicity, I would like this to be used only with released versions; this consolidates the testing points. Reports of problems with the SVN trunk always go to the mailing list. We should be releasing "often enough" that the successful test coverage improves with each releases, so we need to start building up clear and consistent records of our progress over time. This methodology supports the idea of "alpha" or "beta" release phases, where the same release processes are used to create those deliverables. This will allow the release, testing, and reporting processes to be verified and debugged fully. The resulting data should allow us to ensure we are delivering regular fixes and improvements to the user community, without any known exceptions. The tactical goal of each release should to be focus on delivering a product with steadily increasing stability and device support (whether host, target, or interface). Once we have machine-generated records of certain combinations of hardware having worked with a certain version of OpenOCD, it will be virtually impossible for us to miss regressions with particular hardware combinations. Does this proposal sound acceptable? Cheers, Zach Welch Corvallis, OR _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
