On Oct 9, 2007 11:22 AM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > It isn't a change to /released/ rules, and it isn't a change to general > availability releases.
No, it is. > The only apparent change to the end-user is that there would be no 1.3.x, > and the next release they are told to obtain is 1.4.x or later. The problem is that all of the downstream users have to change their own compatibility rules to adjust for us reneging on our release policies. Serf and Subversion would have to be substantially tweaked to adjust for this as all of APR's versioning policies get thrown out the window as the version tag is no longer usable. > Under the proposed change, ALL 1.3.x releases would be initially alpha, > and then beta, and then - it would die, 1.4.0 would carry on as the 'release' > and follow every versioning rule. Nope. There is simply no semantic to be able to enforce "odd" versions are incompatible at run-time. We rely upon library versioning semantics to deal with this. > FWIW ONLY THE 1.3.x changes would be mutable in 1.3.x!!! I don't think you fully appreciate what impact this change has on consumers of APR. > You could NOT change APIs introduced in 1.2.0 or prior, in case that point > has been missed. I don't understand the fixation to keeping the 1.x.y semantics if you are so intent on busting the versioning rules. But, I absolutely don't think it's fair to change the rules mid-stream. Either release a 1.3.0-dev snapshot or move trunk to 2.0.0-dev if you think the APIs change substantially and need feedback. However, in my opinion, under no circumstances should we *ever* release a 1.3.1 that isn't compatible with 1.3.0 per the current versioning rules. We committed to those rules and we need to stick to them. The only avenue for changing them is when we go to 2.0 - and even then, I'm not sure I'd support such a change anyway; but at least then, we could entertain that discussion. -- justin
