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 [email protected]"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 [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
