3

I understand that snapshot is something under development, i.e. 1.0-SNAPSHOT is something that will be eventually released as 1.0.

But why do I need it?

Here is the flow:

  • I develop the library with semantic versioning Major.Minor.Revision[.Build] model.
  • I explicitly define Major and Minor while Revision (or Build) is incremented automatically by CI/CD pipeline
  • After PR is accepted and gated build is successfully run new version is published to company's private repository.
  • In dependent project I specify either exact version or floating version Major.+.

Is there any place for SNAPSHOT here?

Pavel Voronin
  • 13,503
  • 7
  • 71
  • 137
  • Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. – guido Oct 11 '17 at 16:30
  • @GUIDO Does it mean `SNAPSHOT` is just a kind of convenience feature and there are no best practices regarding it? – Pavel Voronin Oct 11 '17 at 16:33
  • 1
    @PavelVoronin That means even though there might be good or bad practices using `SNAPSHOT`s. But they might be primarily opinion based. – Naman Oct 11 '17 at 16:42
  • 1
    If you are talking about a floating version I'm asking me are you talking about Maven? No you are not. In Maven it's not possible to define it like this. This is a definition in Gradle. If you like to have such things in Maven you have to use version ranges like `[1.0,2.0)`.. This makes you build non reproducible. If you are consistently following semver you don't need SNAPSHOT's. – khmarbaise Oct 11 '17 at 20:08
  • @khmarbaise It's SBT actually =) But we publish to Nexus as Maven dependencies – Pavel Voronin Oct 11 '17 at 21:45

1 Answers1

3

This is a huge topic. Let me comment on some points that are relevant in our company.

  • We build ear files that contain jars with large dependency trees. In development, you often need to make a fix deep down in the tree. If you use SNAPSHOT versions, everybody will automatically draw these changes in the next build. If you use build numbers, the results have to be propagated from bottom to top, i.e. if you have a dependency hierarchy A -> B -> C and you build a new version of C, you need a new version of B and then a new version of A. Alternatively, you can manage versions with dependencyManagement on highest level (the ear level, in our case) to avoid rebuilding everything after a bugfix change in jar C.

  • Our developers need to build "half features" to show them to our customers during development. These are usually build as SNAPSHOT versions and not put into the deployment pipeline. SNAPSHOT versions allow you to semantically distinguish these versions from those which are meant to go productive.

  • A distinction between SNAPSHOT and release versions can be used as a quick way to guess the quality of an artifact (if all artifacts have number x.y.z, which are good and which are bad?)

  • Build reproducibility is an important goal, but from the discussion with our developers I know that there a different opinions on this. Some developers value if version updates happen "automatically" - they say that "the newest version is always the right version, why should I do all these manual updates?"

J Fabian Meier
  • 33,516
  • 10
  • 64
  • 142
  • There are several moments about `SNAPSHOT` that are not clear to me. At what time do I change version to release? If everything is automated, then "pressing a button" should start a deployment, i.e. publishing to `maven-releases` with the correct version. Second, when I develop my project, should I indeed use `SNAPSOTS` for dependencies at all? And if I do, when and how again do I change to release version? – Pavel Voronin Oct 12 '17 at 09:52
  • 3
    These are the very same questions we are thinking about. If you want to build something that is "potentially shippable", I would start the deployment pipeline and build a release version. If you have project A and project B in your IDE and A depends on B, then it is useful to build local SNAPSHOT versions of B that you use in A because you get fast feedback. If you work on several artifacts in a group, it might be useful to publish SNAPSHOT versions so that other people in your group could develop against them. It is actually hard to define the exact boundary between SNAPSHOT and release. – J Fabian Meier Oct 12 '17 at 11:11
  • I can only endorse Fabian's answer and reasoning. I have been working in 2 projects over the past 4 years, and they're both being developed in similar contexts: many modules and thus, dependencies, both in the frontend (Vaadin and Angular) as well as in the backend (Java/Spring-based microservices). The more we decouple things and grow our dependency tree, the more useful the SNAPSHOT-based versioning scheme becomes. – Octavian Theodor Aug 24 '20 at 15:43
  • In my experience, after the latest SNAPSHOT is successfully tested to an acceptable level (integration or even some forms of acceptance testing) and provided no changes have been checked in, a release can then be created from the exact codebase. – Octavian Theodor Aug 24 '20 at 15:53
  • A source code check-in/commit can trigger a build process yielding, thus, a SNAPSHOT artifact or even the build of the entire dependency tree. When things pass the tests, a manual command can prepare the release/publish of a stable version. – Octavian Theodor Aug 24 '20 at 15:58