Eric Crahen wrote:
I've found that there is a bug in Y.
Several things need to happen for me at this point:
#1.
I need to keep working on A. So I need to be able to patch Y.
This means I need a local copy. Now you can label this
Eric's-hacked-library
This means fix the bug, change the version number or append an
additional string or whatever that match your status. Then store it in
your repository. Then update your references so that you force the use
of this specific version.
You must strive to have y-1.1-patched-by-eric.jar > y-1.1.jar or
y-1.1-patched-by-eric.jar evicting y-1.1.jar depending your internal
policy., etc...
When a version 1.2 will be released (which hopefully will incorporate
your patch), then 1.2 automatically obsolete 1.1-patched-by-eric (unless
the version is really forced with force=true)
When you do this dependencies are really managed rather than hacked and
there is always the visual element to make sure that the version that is
included is really the latest version and it conveys immediately the
information that this dependency is patched.
If we follow this patching/overriding logic, that means that people
could well do the same on external repositories and silently swap one
jar with another patched version because they are too lazy to do a
release, which basically means that 2 people could be using the same
version with a different code. That's brilliant to convince developers
to commit suicide. :)
And this is also another reason why I don't use external repositories.
1) I trust no one.
2) dependencies are generally not well expressed
3) versioning is sometimes not even well done correctly
4) I keep full control of all my dependencies
5) I have flexibility.
-- stephane
