On Wed, March 16, 2005 3:20 pm, Martin Cooper said: > Upgrading from 1.2.6 to 1.2.7, 1.2.8, etc. is still upgrading. If the > people that make decisions don't let you upgrade, then you're already > stuck. Unless, that is, upgrading to a new dot-dot release is OK, but > a dot release is not. However, if that *is* the case, it is probably > based on the understanding that dot-dot releases are bug fix releases, > which is what the entire software industry, at least as I know it, > uses them to mean.
An argument can be made that the Struts versions are already misused. 1.3 should in fact be 2.0 in my opinion (or 3.0, if the delta was large enough between 1.1 and 1.2.4 so that 1.2.4 should have been 2.0, but I don't remember the differences well enough to say). Sure, you can say that the functionality in 1.3 as far as the public contracts go hasn't changed (i.e., remains compatible at an appliction-level) and therefore does not justify a major version bump, but it is hard to argue that the code base hasn't changed enough to warrant it, and in that regard a business would be better served deciding between a 2.x version and a 3.0 version because it more clearly indicates the degree of change. The bottom line: versioning isn't soley limited to what FUNCTIONALITY has chaged, but how much CODE has changed. You are doing something that is core to Struts in a fundamentally different way, and that carries a higher degree of risk than mearly bug fixes. I also think your interpretation of dot-dot releases is open to debate... Some people do indeed think that a 1.0 and a 1.1 version of something should only differ in being bug fixes, while others feel it should represent only internal changes *or* additions of functionality, both of which are relatively minor (a subjective measure). > You seem to want to inject new functionality into a > dot-dot release to delibrately mislead the decision makers into > allowing you to upgade and get that new functionality while they think > you're only getting bug fixes. Or am I misunderstanding? You are misunderstanding... This is not me trying to make an end-run around some decision makers. It seems like there is a bit of denial going on here... I view 1.3 as not a minor upgrade but a major one because a significant amount of code has changed. This carries with it some risk. What you seem to be saying is that there is a risk moving from 1.2.4 to 1.2.6 for example, but a minor one, and there is a risk moving from 1.2.6 to 1.3, and even though it is a much larger risk (based on the amount of code changes), I should be willing to incur that major risk if I am willing to incur the minor risk in the first place. What I have been saying all along is that some people will not want to go along with that risk. Others may simply not like the direction you guys are taking Struts. A year from now, when 1.3 has been shown to be stable, I doubt anyone will have a problem jumping from 1.2.6 to 1.3 (assuming risk was the deciding factor and not just personal preference), but maybe not right away. You know, I didn't think so before, but maybe I am in fact proposing a fork. Maybe there is enough difference between the 1.2 branch and the 1.3 branch (and more importantly, where the 1.3 branch is going) that an actual fork is in fact warranted. That wasn't what I started out saying, but I'm not so sure any more it isn't what I subconsciously meant. > Perhaps we should just call the current trunk 1.2.7? If you think it's > OK to add significant new functionality into a dot-dot release, why > would we change the dot version for what is in trunk now? What > distinguishes one dot release from another of dot-dot releases can > also include significant new functionality? Again, I believe the version numbers are not being used correctly. I can't speak to what the current version should be, but I do know what the next version should be basde on what we have now: 2.0. >From there on, 2.x represents versions with new or changed features, and 2.x.x represents versions with JUST bug fixes. That is the standard I have seen followed far more frankly. But the more cogent point is the major version bump. The other issue is simply what to do with the current branch. I don't for one second disagree that letting it wither and die (as far as feature changes go) is standard practice. That does not make it the best answer though. Like I said, maybe I'm really talking about an incompatible branch. I don't really like that idea, but I like being essentially forced to 1.3 even less. Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
