Torsten I dont get the analogy either - I didnt see how it helped prove your point. I understand your arguments though, and I can see your point, but I still can't see any convincing arguments for mandating this type of approach. Best left to the individual project maintainers, IMHO.
"Jakarta Commons Developers List" <commons-dev@jakarta.apache.org> wrote: > > On 10/30/06, Torsten Curdt <[EMAIL PROTECTED]> wrote: > > > There are clearly good reasons / circumstances to take the approach > > > you suggest, but it is a user unfriendly approach. As a user I like to > > > try out new versions by dropping in a new jar - before taking the > > > decision to upgrade. This approach rules that out and it wouldn't > > > surprise me if users started to see commons as irrelevant because of > > > "upgrade hell" if we take this route too often. > > > > Guys, you cannot always just "drop in a new jar". Come on! > > > > A similar conversation that could have happened a couple of years ago... > > > > you: "No, I don't like this 3.5" floppy drives. They don't fit my 5 1/4" > > disks!" > > me: "Well, it's new, it's different ...it has more capacity!" > > you: "Well, I don't care ...I used to be able to use them. I don't > > want the new disks ...but the capacity would be great. I just want to > > have that." > > me: "Just keep using you old drive then ...but you would have to stick > > with the old capacity" > > you: "No, now I want the bigger capacity!!" > > me: "Then you will have to copy over the data from the old disks to > > some new ones" > > you: "Are you kidding? That's too much work! I used to just stick them > > in there and they just worked fine! If it's that much work to use this > > new fancy drives - no one will use this crap" > > me: *sigh* > > *silence* > > > > (you = multiple people arguing in this thread not to change the package > > name) > > (me = the other people arguing in this thread who think it would > > probably make sense) > > (silence = the rest of the gang ;-) ) > > I didn't argue in this thread against changing package names - just > against mandating it as a policy. > > I agree that if, as in the example of Generified Collections, the > developers choose to refactor then changing the package name is a > necessary approach. However the Collections developers have/had a > choice - they could have adopted the approach Sun took to generics and > preserved backwards compatibility. Both options are valid - but it > should be down to individual components to choose the route they take. > If Collections had chosen this route then mandating a package name > change would be stupid. > > Niall > > P.S. Your analogy is irrelevant as it doesn't represent any POV I put forward. > > > Keep in mind you can still use the "drop in upgrade" for minor > > releases. If there is a major release - there is a good reason for it! > > If this "drop in" would have been possible it would have been a minor > > release. So how often would you thinks this will happen? And... > > > > Upgrading a package name change is easily manageable by the average > > user ...dependency hell is not. > > > > So I think using this scheme would make things quite transparent and > > HELP the users. > > > > cheers > > -- > > Torsten > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > ----------------------------------------------------------------- Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
