1

I work with a small team that manages a large number of very small applications (~100 Portlets). Each portlet has its own git repository. During some code I was reviewing today, someone made a small edit, and then updated their pom.xml version from 1.88-SNAPSHOT to 1.89-SNAPSHOT. I added a comment asking if this is the best way to do releases, but I don't really know the negative consequences of doing this.

Why not do this? I know snapshots are not supposed to be releases, but why not? What are the consequences of using only snapshots? I know maven will not cache snapshots the same as non-snapshots, and so it may download the artifact every time, but let's pretend the caching doesn't matter. From a release-management perspective, why is using a SNAPSHOT version every time and just bumping the number a bad idea?

UPDATE: Each of these projects results in a war file that will never be available on a maven repo outside of our team, so there are no downstream users.

xdhmoore
  • 8,935
  • 11
  • 47
  • 90
  • 1
    It would be using a snapshot more like a release version, but without the benefits... Snapshots are dev versions, likely to break and evolve at any time. See also http://stackoverflow.com/questions/5901378/what-exactly-is-a-maven-snapshot-and-why-do-we-need-it. The answers there are discussing this issue. – Tunaki Oct 10 '16 at 19:35
  • What are the benefits? Aside from caching? My question is not what SNAPSHOTS are conceptually. I understand the intended purpose. My question is what are the actual benefits of not using snapshots for releases, specifically for internally-deployed wars that will never be on a public maven repo? – xdhmoore Oct 10 '16 at 20:52
  • Because SNAPSHOT is intended to be used for artifact in developement. They are not intended to be used as "release" version. Mind you, you could make it work somewhat, but every developer that knows Maven coming to your project won't understand a thing and that's not good... – Tunaki Oct 10 '16 at 20:54
  • How does maven handle snapshots differently aside from caching? Can the caching change negatively affect release management if your artifacts are only used internally within your small team? – xdhmoore Oct 10 '16 at 20:57
  • You're missing the point, snapshot was not intended for this usage. Like I commented above, you will be able to make it work by having an "always" update snapshot policy for example. But the people depending on your projects will be confused. What is the actual gain of only using snapshots here? Why don't you want to release stable version with a proper release number, tagged on SCM, like everyone does? – Tunaki Oct 10 '16 at 21:02
  • I would prefer to do it the "right" way, but I'm trying to learn more about why so I can give better feed back on a code review. Our maven repo is private to our small team of ~10 and these artifacts are wars, so we shouldn't have to worrry about downstream people. How does the "always" snapshot policy come into play? – xdhmoore Oct 10 '16 at 21:07
  • There are tools to manage this, for example `versions-maven-plugin` or the `maven-release-plugin` that will take care of the versioning when releasing, and it won't let you release a snapshot... Snapshot (just like release) have an update policy that is set to daily by default. But if you push new versions at any change, you won't even see the difference since the users will be forced to update the version. But this will add lots of config for the users if they want to use `maven-release-plugin`... A lot more pain for nothing. The Maven ecosystem assumes a specific definition of a snapshot. – Tunaki Oct 10 '16 at 21:16

2 Answers2

2

The main reason for not wanting to do this is that the whole Maven eco-system relies on a specific definition of what a snapshot version is. And this definition is not the one you're setting in your question: it is only supposed to represent a version currently in active development, and it is not suppose to be a stable version. The consequence is that a lot of the tools built around Maven assumes this definition by default:

  1. The maven-release-plugin will not let you prepare a release with a snapshot version as released version. So you'll need to resort to tagging by hand on your version control, or make your own scripts. This also means that the users of those libraries won't be able to use this plugin with default configuration, they'll need to set allowTimestampedSnapshots.
  2. The versions-maven-plugin which can be used to automatically update to the latest release version won't work properly as well, so your users won't be able to use it without configuration pain.
  3. Repository managers, like Artifactory or Nexus, comes built-in with a clear distinction of repositories hosting snapshot dependencies and release dependencies. For example, if you use shared Nexus company-wide, it could be configured to purge old snapshots so this would break things for you... Imagine someone depends on 1.88-SNAPSHOT and it is completely removed: you'll have to go back in time and redeploy it, until the next removal... Also, certain Artifactory internal repositories can be configured not to accept any snapshots, so you won't be able to deploy it there; the users will be forced, again, to add more repository configuration to point at those that do allow snapshots, which they may not want to do.
  4. Maven is about convention before configuration, meaning that all Maven projects should try to share the same semantics (directory layout, versioning...). New developers that would access your project will be confused and lose time trying to understand why your project is build the way it is.

In the end, doing this will just cause more pain on the users and will not simplify a single thing for you. Probably, you could make it somewhat work, but when something is going to break (because of company policy, or some other future change), don't act surprised...

Tunaki
  • 132,869
  • 46
  • 340
  • 423
1

Tunaki gave a lot of reasonable points why you break Maven best practices, and I fully support that view. But even if you don't care about "conventions of other companies", there are reasons:

  1. If you are not doing CI (and consider every build as potential release), you need to distinguish between versions which should go productive and those who are just for testing. If everything is SNAPSHOT, this is hard to do.

  2. If someone (accidentally) deploys a second 1.88-SNAPSHOT, it will be the new 1.88-SNAPSHOT, hiding the old one (which is available by a concrete timestamp, but this is messy). Release versions cannot be deployed twice.

J Fabian Meier
  • 33,516
  • 10
  • 64
  • 142