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 ;-) ) 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]
