Dangerous new bug in sbt 0.13.2 - Maven POM dependency versioning

[Hanns Holger Rutz]

I was about to commit a new version of a library of mine via Sonatype,
but luckily double checked the POM. Something very odd is happening
which must be related to a switch from sbt 0.13.1 to "bugfix only
version" 0.13.2:

https://oss.sonatype.org/service/local/repositories/desciss-1139/content/de/sciss/scalaaudiofile_2.10/1.4.2/scalaaudiofile_2.10-1.4.2.pom

The entry in question is this

<dependency>
<groupId>de.sciss</groupId>
<artifactId>serial_2.10</artifactId>
<version>[1.0, 1.1)</version>
</dependency>

which was produced by

"de.sciss" %% "serial" % "1.0.2+"

which until now meant, "version 1.0.2 or any higher minor version"

For comparison, here is another POM released with a recent sbt version:

http://search.maven.org/remotecontent?filepath=de/sciss/scalacollider_2.10/1.11.1/scalacollider_2.10-1.11.1.pom

Note entries:

<dependency>
<groupId>de.sciss</groupId>
<artifactId>scalaosc_2.10</artifactId>
<version>1.1.2+</version>
</dependency>
<dependency>
<groupId>de.sciss</groupId>
<artifactId>scalaaudiofile_2.10</artifactId>
<version>1.4.1+</version>
</dependency>
<dependency>
<groupId>de.sciss</groupId>
<artifactId>processor_2.10</artifactId>
<version>0.2.+</version>
</dependency>
<dependency>
<groupId>de.sciss</groupId>
<artifactId>scalacolliderugens-core_2.10</artifactId>
<version>1.8.+</version>
</dependency>

The correct semantics are preserved.

So sbt 0.13.2 seems to silently drop support for specifying the minimum
minor version? This is very bad IMO because now you can break code when
for example version 1.0.0 is used instead of 1.0.2 and 1.0.2 added a
class or a member to a singleton object, something that is binary
compatible and forward compatible.

Should I revert to sbt 0.13.1?

Best, .h.h.

[Josh Suereth]

On Tuesday, April 15, 2014 4:14:21 PM UTC-4, Hanns Holger Rutz wrote:

I was about to commit a new version of a library of mine via Sonatype,
but luckily double checked the POM. Something very odd is happening
which must be related to a switch from sbt 0.13.1 to "bugfix only
version" 0.13.2:

https://oss.sonatype.org/service/local/repositories/desciss-1139/content/de/sciss/scalaaudiofile_2.10/1.4.2/scalaaudiofile_2.10-1.4.2.pom

The entry in question is this

    <dependency>
      <groupId>de.sciss</groupId>
      <artifactId>serial_2.10</artifactId>
      <version>[1.0, 1.1)</version>
    </dependency>

which was produced by

    "de.sciss" %% "serial" % "1.0.2+"

which until now meant, "version 1.0.2 or any higher minor version"

Hmm, actually the semantics in the above are inexpressible in maven.   The above is the closest approximation we can provide.   For ivy/maven this should still lead to correct resolution of the 1.0.2+ artifact given the assumptions that:

• The 1.0.2 artifact had to exist for Ivy to translate it
• Maven/Ivy will also find at least this 1.0.2 artifact when dependent projects depend on this pom.

 

For comparison, here is another POM released with a recent sbt version:

http://search.maven.org/remotecontent?filepath=de/sciss/scalacollider_2.10/1.11.1/scalacollider_2.10-1.11.1.pom

Note entries:

    <dependency>
      <groupId>de.sciss</groupId>
      <artifactId>scalaosc_2.10</artifactId>
      <version>1.1.2+</version>
    </dependency>
    <dependency>
      <groupId>de.sciss</groupId>
      <artifactId>scalaaudiofile_2.10</artifactId>
      <version>1.4.1+</version>
    </dependency>
    <dependency>
      <groupId>de.sciss</groupId>
      <artifactId>processor_2.10</artifactId>
      <version>0.2.+</version>
    </dependency>
    <dependency>
      <groupId>de.sciss</groupId>
      <artifactId>scalacolliderugens-core_2.10</artifactId>
      <version>1.8.+</version>
    </dependency>

The correct semantics are preserved.

This is an invalid POM and actually doesn't work with Maven, as maven doesn't support the +.  Technically you shouldn't be publishing this kind of thing to a maven repository but only to Ivy.  

 

So sbt 0.13.2 seems to silently drop support for specifying the minimum
minor version? This is very bad IMO because now you can break code when
for example version 1.0.0 is used instead of 1.0.2 and 1.0.2 added a
class or a member to a singleton object, something that is binary
compatible and forward compatible.

Should I revert to sbt 0.13.1?

 

This was actually a bugfix for breaking maven consumption of artifacts.  Generally, things like + should not show up in published POM files as they cause major issues, especially given that the conflict manager picks "latest" version and ignores these kinds of constraints in Ivy/Maven by default ANYWAY.

There's a possibility of having the generated "published" pom.xml remove all version ranges for specific ranges as a workaround *OR* just error making pom.xml files if the user has any `+` syntax in it.

In either case, the above *should* be working ok.  If it's not, one of our assumptions is wrong and we can look at an alternative solution.   As it stands, the previous pom.xml files are invalid and we need to fix that.

If you want, you can revert to 0.13.1 to continue publishing invalid pom files, you could publish to an ivy repository *or* you could override the makePom task in your build (I believe pomPostProcess gives you want you need).

[eugene yokota]

Hi Hanns,

On Tue, Apr 15, 2014 at 1:14 PM, Hanns Holger Rutz <con...@sciss.de> wrote:

which was produced by

    "de.sciss" %% "serial" % "1.0.2+"

which until now meant, "version 1.0.2 or any higher minor version"

According to [dependency][1] revision ending with `+` "selects the latest sub-revision of the dependency module."

[1.0, 1.1) actually sounds correct.

For version 1.0.2 or any higher minor revision, you might want to try something like [1.0.2, 1.1).

-eugene

  [1]: http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency.html 

[Hanns Holger Rutz]

Thanks Josh and Eugene,

if indeed the + notation is not officially supported by Maven, then
[1.0.2, 1.1) sounds about right, but [1.0, 1.1) doesn't...

Since I have been using the + notation for years now and it worked fine
with Scala/SBT projects, I think I will just go back to sbt 0.13.1 for
now, and see how things fall into place.

The other option of cause is to remove the + altogether, but I really
the like the idea of hotfix releases coming automatically in.

Best, .h.h.