Re: [Openocd-development] 1.0 or 0.1?
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 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
[Openocd-development] 1.0 or 0.1?
For me the 0.1 is good enough for now. Also, I will add the .z giving the SVN version used to compile the x.y version We should have 0.1.1123. Only the 0.1 is important for the user. The 1123 is for developers. When 1.0 version will be compiled, we should see some things like 1.0.1239 Regards, Laurent http://www.amontec.com JTAGkey / JTAGkey-Tiny / JTAGkey-HiSpeed maker ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 1.0 or 0.1?
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 smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 1.0 or 0.1?
> 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. 0.7 indicates 70% done to me. Very much workable, but not a finished product. 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. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 1.0 or 0.1?
On Jan 13, 2009, at 9:11 PM, Dean Glazeski wrote: I wanted to say that keeping OpenOCD in the 0.x space seems like a bad idea. There's no point in such a system because the x just becomes the version number for the product, so you may want to consider going to version x. I've always thought the kernel was strange for locking at 2.6.x and I found Java even stranger for staying at 1.0.x. I have no experience with version numbers, but I thought I would throw in my two cents. // Dean Many projects use the x.y.z version numbering scheme. X is the major version, Y is the minor, and Z is the patch level. The idea is that a change that breaks compatibility in a major way or an architectural change causes the major version to be incremented. New features and/ or enhancements that don't break compatibility or change the architecture significantly result in the minor version being incremented. Bug fixes with no significant feature set change result in a patch level increment. For OpenOCD, you can think of 0.1 as 0.1.0. The implication is that the code base doesn't have a stable architecture so the major version is 0. It is the first release in the 0.y.z series, so the minor is set to 1 and the patch level to 0. As bugs are fixed, subsequent releases will have the patch level incremented. If a new feature or enhancement is introduced, the minor version is incremented. Once the architecture and config file syntax settles down, the first stable release can be made and the major version will be set to 1. Java actually follows this pattern for their versioning, but it tracks the language rather than the VM or support libraries. Since Java has not had a major design change to the language, the major version is still 1. There have been new features introduced, so the minor version has changed over the years (currently 1.6). The patch level has also been incremented regularly as they do bugfix releases. Where it gets confusing is that they chose a different marketing version from the release version. Java 6 is really release version Java 1.6.z. The Linux kernel has been bad about following their versioning scheme. The major version is stuck at 2.y.z because there has not been a significant major design or architecture change. The minor version does change but they seem to do so when they feel like it rather than when major features are introduced. The patch level changes for each release even if it sometimes contains new features or major enhancements. I would be perfectly happy to use the x.y.z versioning scheme. As I suggested above, I'd start with 0.1.0 and update the numbers as appropriate for each release. We would eventually get to 1.0.0, but only once we are comfortable with declaring the architecture and config syntax are stable. -- 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 smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 1.0 or 0.1?
Rick Altherr wrote: On Jan 13, 2009, at 11:13 AM, Michael Schwingen wrote: Øyvind Harboe wrote: OpenOCD can *NEVER* be "1.0" in that there will always be a non-trivial effort required on the developers side to get things working. That depends a bit on the feature set that is required for a 1.0 release. If we select platforms that are completely supported (say, ARM7 and XScale?), and get the configuration management to a state where the user only needs to tweak a supplied config file a bit for his board, I think this could be called 1.0 - a 1.0 release does not need to support every device in the world. I think it is just a matter of taste where we draw the line of what needs to be stable for a release. However, having a stable config file syntax that does not change shortly after 1.0 would be good for users. I'd say that 0.9 is as finished as a hardware debugger will ever be if it is to be anything like remotely current w.r.t. hardware out there. So, I vote for 0.7 :-) Fine with me. Now if the development speed stays the same, I do think we should be able to reach something that can be called 1.0 during this year. cu Michael 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. -- 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 I wanted to say that keeping OpenOCD in the 0.x space seems like a bad idea. There's no point in such a system because the x just becomes the version number for the product, so you may want to consider going to version x. I've always thought the kernel was strange for locking at 2.6.x and I found Java even stranger for staying at 1.0.x. I have no experience with version numbers, but I thought I would throw in my two cents. // Dean ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 1.0 or 0.1?
On Jan 13, 2009, at 11:13 AM, Michael Schwingen wrote: Øyvind Harboe wrote: OpenOCD can *NEVER* be "1.0" in that there will always be a non- trivial effort required on the developers side to get things working. That depends a bit on the feature set that is required for a 1.0 release. If we select platforms that are completely supported (say, ARM7 and XScale?), and get the configuration management to a state where the user only needs to tweak a supplied config file a bit for his board, I think this could be called 1.0 - a 1.0 release does not need to support every device in the world. I think it is just a matter of taste where we draw the line of what needs to be stable for a release. However, having a stable config file syntax that does not change shortly after 1.0 would be good for users. I'd say that 0.9 is as finished as a hardware debugger will ever be if it is to be anything like remotely current w.r.t. hardware out there. So, I vote for 0.7 :-) Fine with me. Now if the development speed stays the same, I do think we should be able to reach something that can be called 1.0 during this year. cu Michael 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. -- 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 smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 1.0 or 0.1?
Øyvind Harboe wrote: > OpenOCD can *NEVER* be "1.0" in that there will always be a non-trivial > effort required on the developers side to get things working. > That depends a bit on the feature set that is required for a 1.0 release. If we select platforms that are completely supported (say, ARM7 and XScale?), and get the configuration management to a state where the user only needs to tweak a supplied config file a bit for his board, I think this could be called 1.0 - a 1.0 release does not need to support every device in the world. I think it is just a matter of taste where we draw the line of what needs to be stable for a release. However, having a stable config file syntax that does not change shortly after 1.0 would be good for users. > I'd say that 0.9 is as finished as a hardware debugger will ever be if > it is to be anything like remotely current w.r.t. hardware out there. > > So, I vote for 0.7 :-) > Fine with me. Now if the development speed stays the same, I do think we should be able to reach something that can be called 1.0 during this year. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 1.0 or 0.1?
On Tue, Jan 13, 2009 at 8:36 AM, Michael Schwingen wrote: > > Rick Altherr wrote: > > It's been a while since any talk about 1.0 has flown by on the list. > > My take on recent developments is that calling what we have today 1.0 > > is a bit of a stretch. The ToT codebase works on in a few > > interface/target combinations, but there are still lots of mysterious > > errors. My investigations into how to add Cortex-A8 support has led > > down a few thought experiments that would cause major changes to both > > the code base and to the configuration syntax. All of these things > > don't make the current ToT feel like a 1.0. Since the main intent of > > a versioned release is to provide an easy way for users to obtain and > > build a known version, we don't really need to have an extremely solid > > first release. I'd suggest that we clean up the current ToT and > > release a 0.1. That way, the various package maintainers can use a > > known version and hopefully users will focus on using 0.1 instead of > > battling with the current ToT and the bugs it has had introduced. > I think it feels more like at least 0.5, or even 0.9 - depending on > target. However, it is just a number, for me, any will do fine as long > as we *do* a release. OpenOCD can *NEVER* be "1.0" in that there will always be a non-trivial effort required on the developers side to get things working. I'd say that 0.9 is as finished as a hardware debugger will ever be if it is to be anything like remotely current w.r.t. hardware out there. So, I vote for 0.7 :-) -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 1.0 or 0.1?
Rick Altherr wrote: > It's been a while since any talk about 1.0 has flown by on the list. > My take on recent developments is that calling what we have today 1.0 > is a bit of a stretch. The ToT codebase works on in a few > interface/target combinations, but there are still lots of mysterious > errors. My investigations into how to add Cortex-A8 support has led > down a few thought experiments that would cause major changes to both > the code base and to the configuration syntax. All of these things > don't make the current ToT feel like a 1.0. Since the main intent of > a versioned release is to provide an easy way for users to obtain and > build a known version, we don't really need to have an extremely solid > first release. I'd suggest that we clean up the current ToT and > release a 0.1. That way, the various package maintainers can use a > known version and hopefully users will focus on using 0.1 instead of > battling with the current ToT and the bugs it has had introduced. I think it feels more like at least 0.5, or even 0.9 - depending on target. However, it is just a number, for me, any will do fine as long as we *do* a release. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] 1.0 or 0.1?
It's been a while since any talk about 1.0 has flown by on the list. My take on recent developments is that calling what we have today 1.0 is a bit of a stretch. The ToT codebase works on in a few interface/ target combinations, but there are still lots of mysterious errors. My investigations into how to add Cortex-A8 support has led down a few thought experiments that would cause major changes to both the code base and to the configuration syntax. All of these things don't make the current ToT feel like a 1.0. Since the main intent of a versioned release is to provide an easy way for users to obtain and build a known version, we don't really need to have an extremely solid first release. I'd suggest that we clean up the current ToT and release a 0.1. That way, the various package maintainers can use a known version and hopefully users will focus on using 0.1 instead of battling with the current ToT and the bugs it has had introduced. Thoughts? -- 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 smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
