Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Let's say I have artifacts "mylibrary-5.2.jar" and "mylibrary-5.3.jar" representing the 5.2 and 5.3 versions of a library that our project creates and publishes for one of our other projects.

Does Artifactory support having multiple "versions" of each of these artifacts to represent the different builds that were performed during a release to construct this artifact?

For example, to produce the final version of the 5.2 release of "mylibrary" aka the artifact: mylibrary-5.2.jar, we went through 3 builds to get to a version that passed our integration environment's automated tests and our user acceptance tests.

So there were three separate builds that produced three separate artifacts for release 5.2. We want to be able to retain and potentially recall these different build's artifact at a later date (for testing, etc).

In order to do this, which of the following options would work?

  1. Capture the artifacts as separate Artifacts, i.e. build-5.2-b1.jar (build 1's artifact), build-5.2-b2.jar (build 2's artifact), build-5.2-b3.jar (build 3's artifact), and build-5.2.jar (the final production release; which matches build 3)

  2. Capture a SINGLE artifact named "build-5.2.jar" which has VERSIONS of the artifact which capture builds 1 through 3 and which can be recalled later, by version number.

  3. Some other option we have not considered, but should
share|improve this question
up vote 1 down vote accepted

The usual way to do this is create each build with a separate version number. For example, 5.2.RC1, 5.2.RC2, and so on ("RC" is "release candidate"). Then make a final version that's 5.2.RELEASE.

I believe (no evidence) that version 5.2.RC1 is considered "newer" than 5.2, which is why companies that do this tend to go with 5.2.RELEASE as the final version.

You might be able to tell Artifactory to not remove snapshots when the release version is deployed. Since each snapshot is written to the repository with a unique datestamp, this will give you the history you want.

You definitely do not want to combine different versions into a single JAR. That will just make your life more difficult trying to use that JAR.

And really, I think you'll find the benefit of keeping each release candidate to be pretty low. Unless, of course, you're in some highly regulated or litigated field, where you must keep each version to satisfy the regulators/lawyers.

share|improve this answer
We usually put releases and snapshots in different repositories. – TMN Aug 8 '12 at 18:44
Same effect whether it's in the same repository or different; the snapshots are stored with a datestamp, so provide history (and by "different repositories," do you mean different servers or different repositories within the same server? and if the former, why?) – parsifal Aug 8 '12 at 19:52
Different servers, in this case. The release server allows external access for our development partners, but snapshots are only internal so we keep them on a server behind the firewall. – TMN Aug 9 '12 at 11:38

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.