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]
