Visit my.sonatype.com for documentation on Nexus Repository version 2.
Releases are forever, right? Once you’ve pushed an artifact to a hosted release repository, it is etched in stone, and changing it is a bad practice. That’s what we’ve been saying since we launched Nexus Repository 2, but there are situations that call for old releases to be deleted. In fact, there are situations that require the deletion of old releases. Otherwise, you’d be paying for terabytes of useless data storage.
Sometimes Releases are Disposable
For example, consider a company that creates a large, web-based system. They may deploy new versions of components to production multiple times a day. If this seems unrealistic, know that system administrators for popular services like Facebook, Last.fm, and Flickr have talked openly about how frequently code is pushed to production systems. A few times a day isn’t odd in some of these environments, and with a large system, you’d consume terabytes of space to keep all of those old releases around.
Last time I worked at a large, consumer-focused web site, pushing something to production once a day wasn’t uncommon, and even the idea of rolling back to anything other than yesterday’s build was laughably impractical. If you identified a bug in a CMS or a production database, you’d just fix it and move on. This is especially true of larger, web-facing systems in which the only reality is the code that is running in production today. A site like Flickr gains nothing from being able to roll back to a release from last September.
The Other Side of the Coin: Releases are Forever
Compare this to the production release schedule of a critical, supported product; it’s like night and day. If you are coding some serious banking system, you might be lucky to have a release once a month. In all likelihood you might be looking at a quarterly release. When you are working on critical applications, ship software, or have infrequent release cycles, the ability to roll back to previously released binaries is very important. When you work in a fast-paced environment with a very short release cycle, there’s not much value in retaining older releases.
For this reason, we’re clarifying this point: If it makes sense for you to delete release artifacts from a hosted repository, go for it. Just remember to re-index the server once you’ve manipulated the storage folder.
If you decide that you do want to remove old releases, Nexus Repository makes this easy. Using the "Remove Releases From Repository" scheduled task, you can trigger the deletion of release components. This results in supporting these use cases, taking care of meta data updates, and removing the need to manually delete the components or use an external system to trigger the deletion.
To configure the task, you specify the repository in which released components are to be deleted as well as the number of component versions to keep for a specific group_Id and artifact_Id coordinate. The task generates a list of all versions of a component for each group_Id and artifact_Id coordinate combination and sorts it according to the version number. The ordering is derived by parsing the version string and supports semantic versioning with additional semantics for specific classifiers. Further details can be found in the documentation for the implementing class GenericVersionScheme.