It is a minor, rather than bugfix. So I think it's fair to say "Please recompile". However, also good to keep backwards compat when it's not too painful.
Seeing how I'm about to go down a similar road with commons-email... I'm okay with requiring a recompile as long as you're not requiring drastic changes in the client source code.
1) Why not deprecate the public fields in HelpFormatter rather than > making them private? I think it's a simple enough change for people to adjust to this one if they discover they've used the public fields. So I'd like to be bold on this one and not put the public fields back in.
Again, works for me as long as it's not onerous. Agreed. It's a pain for someone if they've actually used the clone().
I don't see any great needs to clone options, however someone did report a bug with it so that would imply that someone wanted to clone.
Implementing clone() properly is a pain and hard to get right. If someone really needs distinct copies of Option classes (why?!), I'd suggest providing a copy constructor instead. If compatibility is a really big deal, you could change clone() to call Object.clone(), which throws an exception. Think of it as a gentle hint to the user not to use the method anymore -- and the exception message could also point out the new copy constructor. I think this was a recent change that Brian and I made (need to
check). That method should not, not, not, be called by a user. Option classes are immutable-ish, but behind the scenes the code mutates them. So definitely want to break people who are using this.
+1. My general subscription is that I want to break it if it's bug
related, and deprecate it if the removal is just policy or trivial (ie: renaming, package moving etc). We do need to sort out the clone one, others I think can stay (consensus pending).
Concur -- if it's broken, break it; don't wallpaper over it, because some poor sod *will* put his head through it eventually.
