Jason van Zyl wrote:
If the production of a JAR was in fact unchanged then I agree that it should not be release again. If that's the case then it would be a best practice to document this but you can't rely on this as sometimes people just won't document things. What if the md5sum for the last release still holds true for the JAR produced? If the md5sum is the same then it's not a candidate for release. The POM is packaged up in every JAR so even if the POM changed the md5sum would be different. I guess we need to decide if a change in the metadata is grounds for a release. At first blush I would say yes.
Metadata changes are probably what the -1, -2 increments were designed for - ie nothing has changed, but its being rebuilt anyway.
The md5sum is an interesting idea, but would fall down in some ways - for example if a different version of Maven was used to build it it might change even if the original didn't change (though I guess the justifies a new version, it doesn't indicate to the user much about what changed). Some invocation of clirr might be better (actually, we could use these together to ascertain whether it is different and to what extent).
And you needed to do this just to get a new version with some fixes or because the APIs changed? If there were no API changes and just fixes wouldn't the proper use of ranges (and possibly some conventions) allow for this?
Yes, ranges would solve this. The APIs didn't change - so the code didn't change. This was purely a POM change.
What we need to push towards is what I'd originally intended - that versions specified are "soft" versions, and the latest matching any discovered ranges would be used under the default conflict resolver. Unfortunately conflict resolution fell off the 2.0 feature list and for greater predictability we reverted back to "use nearest" resolution.
So we need to greater document and encourage ranges at this point and work on this as a 2.1 feature for sure, I was just wondering if there were any other thoughts on the matter.
Let's start to adopt ranges on our own code so we can gather better experience with working with them.
- Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
