I agree that we shouldn't lose momentum on doing a release. My failure to make oocd a standard part of my tools so far has had a lot to do with the moving target of the config files (as well as time & cognitive difficulties ;) Supporting the 'biggies' (ARM7 - NXP, Atmel, ST, M3 - Luminary, ST) cleanly seems like a good release point regardless of what we're calling it - might please most of the people most of the time.
x.y.z is fine with me. Steve On Wed, Jan 14, 2009 at 12:55 AM, Rick Altherr <kc8...@kc8apf.net> wrote: > > On Jan 13, 2009, at 11:35 PM, Øyvind Harboe wrote: > >>> The difference between 0.1 and 0.7 is entirely in perception. The >>> version >>> numbers are effectively arbitrary since we have never made any other >>> versioned release. If we are going to use 0.x (the two responses I got >>> have >>> both suggested that path), we might as well start with the beginning of >>> the >>> minor version number space (0.1) rather than an arbitrary point in the >>> middle. >> >> You're contradicting yourself. You say that the version # is about >> perception, >> then you say that 0.7 is arbitrary. >> > > The two are not mutually exclusive. Since there have been no versioned > releases, the first number is entirely arbitrary since we need to pick a > number but it has no meaning within the project itself. But it also means > that users will perceive a meaning based on comparisons to other projects. > >> 0.7 indicates 70% done to me. Very much workable, but not a finished >> product. >> > > Sure, but 0.1 can just as easily indicate the first release that we feel is > acceptable for users to test. The number has no intrinsic meaning at this > point since it is the first one. Any meaning attached to the number isn't > likely to make any sense to a general user. In fact, choosing something > like 0.7 could just as easily cause more confusion than confidence. Someone > will ask where versions 0.1-0.6 are. Saying we chose 0.7 because we wanted > people to have more confidence that it was stable or because we wanted to > give the impression that it was close to a 1.0 feels like an attempt to > mislead. > >> A JTAG debugger is 100% done by the time it is obsolete, so it is a >> product, >> unlike others that *must* and *should* be used before it is finished. >> > > Every software project suffers the same fate. There are always new features > to add, bugs to fix, and better architectures. Version 1.0 doesn't mean a > project is done, just that it has reached a point where it is good enough > for general use. Otherwise, Microsoft Office wouldn't be working on version > 14.0. > >> >> -- >> Øyvind Harboe >> http://www.zylin.com/zy1000.html >> ARM7 ARM9 XScale Cortex >> JTAG debugger and flash programmer > > -- > Rick Altherr > kc8...@kc8apf.net > > "He said he hadn't had a byte in three days. I had a short, so I split it > with him." > -- Unsigned > > > > > _______________________________________________ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
