> NBANDROID uses a special web server, which changes the implementation > version of the dependencies in the modules, but it's not a clean > solution... > And I would like it to be finally resolved. Because it makes module > developers trouble... >
Using the build number serves an important purpose: If you are making no compatibility guarantees, then the only thing that's reliable that two libraries are actually compatible is if the answer is "yes" to the question "were both of these things compiled as part of the same build?". Fix that in NBANDROID, not globally. *However, what would be the pros and cons or possibilities of making implementation and specification versions the same? Given we already increment all specification versions between releases, this should achieve the same purpose for anyone not utilising daily builds?* It will break more things than it fixes and just create new problems. Some modules use semi-stable values for implementation version - they aren't official API but they change rarely if at all, and a module built against those will work across releases without someone having to download a new JAR whose only difference may be a dependency version string. Anyone developing a module against those will suddenly start having exactly the problem you want to solve - needing to cut a new release for every increment of the spec version. We discussed this long ago, but if you want fewer friend dependencies, then the solution is to get more of those through the API review process and committed to as stable API. That's what it's for, and that's what actually solves the problem. -Tim
