Well said, and I completely agree. My original point is your point #1 just isn't possible with the current versioning scheme. Because every release gets its own patch number, regardless of quality or API changes, it can't be counted on, and really, I don't see any solution other than creating a big matrix of releases for users to somehow navigate the sea of releases to understand which are compatible with the other.
Don On 2/22/08, Brian Pontarelli <[EMAIL PROTECTED]> wrote: <snip /> > The solution is this: > > 1. Pick a versioning scheme. I suggest that minor numbers indicate > compatibility such that 2.1.x are all compatible but 2.1 is not > compatible with 2.2. This seems to be the pattern. This is commonly > referred to as "patch" compatibility since things are only compatible > across patch version numbers like 2.1.1 and 2.1.2. > > 2. Tell developers that if the minor numbers in the version aren't > changing, they can't break any public APIs runtime compatibility. > > That should be it. Simple, straight-forward and still allows each > release to have its own version number. Then the tools can correctly > manage dependencies. > > > -bp > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
