On Wed, Mar 6, 2013 at 11:58 PM, Peter Stuge <pe...@stuge.se> wrote: > I generally prefer feature based releases over time based releases.
Nothing wrong with that actually. I mentioned in my previous reply that a few conditions for a release. 1) Major feature 2) Major bug fixes or regression 3) If not (1) and (2), then still a 6-month release with minor features and bug fixes. That 6-month period can be changed depending on the project, it can be 1 year, can be 3-month. But 6 months seems to be good for OpenOCD since there are quite a lot of activities within 6 months. And with feature based release, a roadmap is good to have. Example from libusbx project, which is rather using feature based release as the criteria. https://github.com/libusbx/libusbx/issues/milestones On that note, where is the roadmap for libusb project? > OpenOCD lies toward the opposite end of the resource spectrum from > the Linux kernel, the rate of change is fairly low. That obviously > makes it less important if and how releases happen. > > I think the next major "feature" is the internal organization > cleanup, and the one after that SWD, but those effort are no reason > not to make releases in the meantime, where there will be lots of > very good smaller changes. Good to know that. I agree with you that the SWD is an important feature. I do not see it happend any time soon though. On the other hand, I thought you were against Freddie's idea of carrying out the release of 0.7.0 in the near future. But your above statements conflicted with those comments (only need a cronjob for a time based release, etc). > If it becomes necessary to break something as part of the cleanup > then I think that needs to take place in a separate branch, so that > we can continue to have master always releaseable. > > Although more discussion seems to be needed about if and how master > can be considered releaseable - I refer to Freddie's concern about > regressions. > > I for one don't find regressions unacceptable, as long as they are > fixed again. If they can be avoided of course that is best, review > is one tool to do just that, testing is another great help, but > testing when hardware is involved is always tricky. > > That is not to say that all testing of OpenOCD is useless! I think > there could be lots of useful tests for OpenOCD. I think it would > be great to give Jenkins more to do! All the above are valid inputs. -- Xiaofan ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
