Binary version, binary compatibility and cross versioning

[Grzegorz Kossakowski]

Hi,

I'd like to restart discussion about binary compatibility assumptions in sbt. This is continuation of the discussion in https://github.com/harrah/xsbt/pull/600. I expect our discussion to continue for a while that's why I decided to start a new thread on mailing list.

The latest proposal by Mark is here: https://github.com/harrah/xsbt/pull/600#issuecomment-11885342

Being Scala compiler hacker I mostly understand binary compatibility considerations related to Scala itself. I'd like other people (probably Mark) to comment on sbt plugins and binary compatibility.

In Scala we intend to use the following version format (since 2.10.0 release) for stable releases:

epoch.major.minor[-hotfix]

Epoch is increased only to communicate a whole new generation of Scala the language (the compiler). It happened only once so far.

Major component is increased whenever Scala breaks binary compatibility.

Minor component is increased whenever a new Scala release comes out that is binary compatible with releases epoch.major.{minor-1}..0. Minor releases are mostly about bug fixes and minor improvements to existing features (that do not break binary compatibility).

The [-hotfix] is introduced in exceptional cases when it turns out that latest minor release (against which [-hotfix] is released) had a major problem that was discovered last minute and has to be fixed ASAP. The hotfix part is always a number. I believe the reason [-hotfix] is attractive (instead of just bumping minor version) is the fact that Maven has special treatment of [-hotfix] but I couldn't find any reference. I'd prefer to get rid of [-hotfix]. It's very likely it will happen so we'll have just three components consisting of three digits.

Increase of one component restarts counters for all components on the left. E.g. the first stable version with epoch=2,major=10 is going to be 2.10.0.

Scala also publishes milestones and release candidates and asks library authors to release against those versions. Both milestones and release candidates are not stable.

Let's consider milestones first. Version number for milestone are always of format:

epoch.major.0-Mn

where n is a number denoting nth milestone leading to epoch.major.0 release. Milestones are counted from 1. Milestones are not guaranteed to be binary compatible against any version.

We also have RCs. There are two different kind of RCs. There are RCs leading to a new major release that are of the format:

epoch.major.0-RCn

Once epoch.major.0-RC1 is out there will be no more milestone for epoch.major. Release candidates leading to new major version are not guaranteed to be binary compatible against that new major version.

There are also release candidates leading to new minor release. They are of the format:

epoch.major.minor-RCn

where minor is >= 1. Those releases are guaranteed to binary compatible against all releases with minor version lower than one we consider here.

In addition to persistent version number we have one scheme for nightly builds of the following format:

epoch.major.minor-SNAPSHOT

since those are nightly builds guarantees are weaker (mistakes happen) but the intent is that for minor >= 1 SNAPSHOTs are binary compatible against all minor versions lower than considered here. For minor=0 there is no guarantee about binary compatibility.

Based on all of that we can design a function isAPICompatible (mentioned here):

1. Parse version into {epoch: Int}.{major: Int}.{minor: Int}[-{qualifier: String}] format. If there's a parsing error, issue a warning and return false.
2. Once we have version parsed, we can express the logic using pattern matching:
   version match {
      case (_, major, _, _) if major < 9 => false // no compatibility
      case (_, _, 0, None) => true // covers 2.10.0; major release has been increased and this is a base-point
      case (2, 9, 0, Some("1")) => true // special case for 2.9.0-1 hot fix release
      case (_, _, 0, Some(_)) => false // covers 2.10.0-M1, 2.10.0-RC1 and 2.10.0-SNAPSHOT
      case _ => true // minor > 0, covers 2.9.1-1, 2.10.1, 2.10.1-RC1, 2.10.1-SNAPSHOT
   }

Everywhere above I mentioned "binary compatibility" but there are two kinds of binary compatibility:

• backward compatibility (guaranteed in 2.9.x series)
• forward compatibility

Given various limitations sbt cannot distinguish between those two kinds of binary compatibility. Since most people are familiar with backward compatibility I'll explain forward compatibility and how it matters for sbt. Imagine that in 2.10.1 Scala introduces some new methods in Reflection API. There's library that decides to use those methods and gets released as  "foo" % "bar_2.10" % "1.2.3". Now, there's a project using Scala 2.10.0 and tries to depend on "foo" % "bar" %% "1.2.3" and sbt successfully resolves the dependency according to all considerations above. Obviously, it will blow up during runtime during classloading because the method won't be in scala-reflect.jar of 2.10.0 version. The only way to guarantee forward compatibility is to not add anything new. Scala project hasn't decided if it wants to maintain forward compatibility as it's very restrictive.

If Scala decided to not provide forward compatibility then sbt could help users by warning them about situation described above. What should happen is that once dependency resolution is done, sbt would analyze all dependencies of a project and check their dependency on scala-library. If given library depends on newer[*] version of Scala than the one used by the project sbt would warn the user about potential problems with binary compatibility. I believe mechanism like that is already in sbt but I don't know how robust it is. Mark, could you comment on that part?

Feedback is welcome!

[*] we would need an ordering on Scala version numbers but that's easy to do for stable versions

--
Grzegorz Kossakowski

[Doug Tangren]

[*] we would need an ordering on Scala version numbers but that's easy to do for stable versions

I have a standalone lib for doing just that based on http://semver.org/ -  https://github.com/softprops/semverfi

 

--
Grzegorz Kossakowski

--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To post to this group, send email to simple-b...@googlegroups.com.
To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.

[Mark Harrah]

On Fri, 4 Jan 2013 14:15:35 -0800
Grzegorz Kossakowski <grzegorz.k...@gmail.com> wrote:

> Hi,
>
> I'd like to restart discussion about binary compatibility assumptions in
> sbt. This is continuation of the discussion in
> https://github.com/harrah/xsbt/pull/600. I expect our discussion to
> continue for a while that's why I decided to start a new thread on mailing
> list.
>
> The latest proposal by Mark is here:
> https://github.com/harrah/xsbt/pull/600#issuecomment-11885342
>
> Being Scala compiler hacker I mostly understand binary compatibility
> considerations related to Scala itself. I'd like other people (probably
> Mark) to comment on sbt plugins and binary compatibility.

The RCs for 0.12.0 were all binary compatible with each other and what became 0.12.0. It is not guaranteed, but it is true often enough that the sbt major.minor version is sufficient for versioning plugins.

[...]

> Based on all of that we can design a function isAPICompatible (mentioned

> here <https://github.com/harrah/xsbt/pull/600#issuecomment-11593459>):

The brief context is that isAPICompatible is used to determine whether the cross-version suffix should be major.minor or the full version. Only if isAPICompatible is true for a version is major.minor used.

> 1. Parse version into {epoch: Int}.{major: Int}.{minor:

> Int}[-{qualifier: String}] format. If there's a parsing error, issue a
> warning and return false.

> 2. Once we have version parsed, we can express the logic using pattern

> matching:
> version match {
> case (_, major, _, _) if major < 9 => false // no compatibility

Although it seems very unlikely that any sbt version released now will work with Scala 3+, we should not guarantee it will fail. Someone would have to remember to update this method for 3.0 in any case.

> case (_, _, 0, None) => true // covers 2.10.0; major release has been
> increased and this is a base-point
> case (2, 9, 0, Some("1")) => true // special case for 2.9.0-1 hot fix
> release
> case (_, _, 0, Some(_)) => false // covers 2.10.0-M1, 2.10.0-RC1 and
> 2.10.0-SNAPSHOT
> case _ => true // minor > 0, covers 2.9.1-1, 2.10.1, 2.10.1-RC1,
> 2.10.1-SNAPSHOT
> }

isAPICompatible must be consistent across all sbt versions used for a version of Scala. This means that the cross-version suffixes for Scala versions 2.10 and earlier are fixed and cannot change. Consider an sbt 0.12 user publishing for 2.9.2 and 2.10.0. Their cross version suffixes will be _2.9.2 and _2.10. An sbt 0.13 user with the above function would have suffixes of _2.9 and _2.10. Thus, they would not agree on the 2.9 suffix.

If this change is made, it must be made well in advance of 2.11 so that all 2.11 prerelease users are on 0.13. It is only even reasonable to require an update to 0.13 because prerelease users are a smaller group and more likely to be able to update. Those that don't can use the previous technique.

The 2.10.0-* case doesn't matter anymore, since no one will be publishing for those versions. Any changes should only apply to 2.11 or later to ensure compatibility with the current behavior for released Scala versions.

-Mark

[Grzegorz Kossakowski]

On 4 January 2013 19:48, Mark Harrah <dmha...@gmail.com> wrote:

>    1. Parse version into {epoch: Int}.{major: Int}.{minor:

>    Int}[-{qualifier: String}] format. If there's a parsing error, issue a
>    warning and return false.

>    2. Once we have version parsed, we can express the logic using pattern

>    matching:
>    version match {
>       case (_, major, _, _) if major < 9 => false // no compatibility

Although it seems very unlikely that any sbt version released now will work with Scala 3+, we should not guarantee it will fail.  Someone would have to remember to update this method for 3.0 in any case.

Agreed.

 

>       case (_, _, 0, None) => true // covers 2.10.0; major release has been
>    increased and this is a base-point
>       case (2, 9, 0, Some("1")) => true // special case for 2.9.0-1 hot fix
>    release
>       case (_, _, 0, Some(_)) => false // covers 2.10.0-M1, 2.10.0-RC1 and
>    2.10.0-SNAPSHOT
>       case _ => true // minor > 0, covers 2.9.1-1, 2.10.1, 2.10.1-RC1,
>    2.10.1-SNAPSHOT
>    }

isAPICompatible must be consistent across all sbt versions used for a version of Scala.  This means that the cross-version suffixes for Scala versions 2.10 and earlier are fixed and cannot change.  Consider an sbt 0.12 user publishing for 2.9.2 and 2.10.0.  Their cross version suffixes will be _2.9.2 and _2.10.  An sbt 0.13 user with the above function would have suffixes of _2.9 and _2.10.  Thus, they would not agree on the 2.9 suffix.

That's a good point! I haven't thought about that one. Fortunately enough, it's easy to fix by adding another case. I don't think having special cases like that is a big deal as long as we agree what to do in the future.

If this change is made, it must be made well in advance of 2.11 so that all 2.11 prerelease users are on 0.13.  It is only even reasonable to require an update to 0.13 because prerelease users are a smaller group and more likely to be able to update.  Those that don't can use the previous technique.

The first milestone of 2.11 is planned for the next week so we'll need to tell people how to tweak their configuration once again.

I agree that sbt 0.13 should have the right defaults so people can forget about the whole issue 90% of the time.

 

The 2.10.0-* case doesn't matter anymore, since no one will be publishing for those versions.  Any changes should only apply to 2.11 or later to ensure compatibility with the current behavior for released Scala versions.

True. Once 2.10.0 is out current sbt defaults will work fine.

--
Grzegorz Kossakowski

[eugene yokota]

Hi,

Mark wrote in #600:

Here is the best shot at something changing. Make the isAPICompatible method properly parse the version intoX.Y.Z-*. If * is an integer or -* is not present, assume it is a release and compatible. Otherwise, including if the version is not in the right form, it is not compatible. We don't need to handle OSGi versions as far as I know. Implement this, update the pull request, send an email to the mailing list, and link to this pull request. I'm not in favor of this for the reasons above, but I know you'll maintain this and deal with ongoing issues. Ideally, I'd like to see some kind of consensus from users who understand the issue.

Based on prior discussion in #600 I included X.Y.1-M1 into X.Y API compatible version. Here's the proposed implementation for isAPICompatible:

def isAPICompatible(v: String): Boolean = apiVersion(v).isDefined

/** Returns binary interface x.y API compatible with the given version string v. 

  * Compatibile versions include 2.10.0-1 and 2.10.1-M1 for Some(2, 10), but not 2.10.0-RC1.

 */

def apiVersion(v: String): Option[(Int, Int)] = {

val ReleaseV = """(\d+)\.(\d+)\.(\d+)(-\d+)?""".r

val NonReleaseV = """(\d+)\.(\d+)\.(\d+)(-\w+)""".r

v match {

case ReleaseV(x, y, z, ht)    => Some((x.toInt, y.toInt))

case NonReleaseV(x, y, z, ht) if z.toInt > 0 => Some((x.toInt, y.toInt))

case _ => None

}

}

And here are some sample usage:

scala> import sbt.CrossVersion.{apiVersion, isAPICompatible}

import sbt.CrossVersion.{apiVersion, isAPICompatible}

scala> apiVersion("2.10.0")

res0: Option[(Int, Int)] = Some((2,10))

scala> isAPICompatible("2.10.0")

res1: Boolean = true

scala> isAPICompatible("2.10.0-1")

res2: Boolean = true

scala> isAPICompatible("2.10.1")

res3: Boolean = true

scala> isAPICompatible("2.10.1-M1")

res4: Boolean = true

scala> isAPICompatible("2.10.1-RC1")

res5: Boolean = true

scala> isAPICompatible("2.10.1-SNAPSHOT")

res6: Boolean = true

scala> isAPICompatible("2.10.0-M1")

res7: Boolean = false

scala> isAPICompatible("2.10.0-RC1")

res8: Boolean = false

scala> isAPICompatible("2.10.0-SNAPSHOT")

res9: Boolean = false

This should select the right default for 2.10.0-M* while allowing future 2.10.x to be 2.10 compatible.

I also rebased the pull request to the latest 0.13 branch.

-eugene

[Mark Harrah]

On Sat, 5 Jan 2013 01:04:03 -0800 (PST)
eugene yokota <eed3...@gmail.com> wrote:

> Hi,
>

> Mark wrote in #600<https://github.com/sbt/sbt/pull/600#issuecomment-11885342>
> :

I think this matches what has been discussed. However, this is also used for sbt, right? sbt RCs, even for .0, should be compatible because that is usually the case, despite not being guaranteed.

-Mark

[Mark Harrah]

> > > case (_, _, 0, None) => true // covers 2.10.0; major release has
> > been
> > > increased and this is a base-point
> > > case (2, 9, 0, Some("1")) => true // special case for 2.9.0-1 hot
> > fix
> > > release
> > > case (_, _, 0, Some(_)) => false // covers 2.10.0-M1, 2.10.0-RC1
> > and
> > > 2.10.0-SNAPSHOT
> > > case _ => true // minor > 0, covers 2.9.1-1, 2.10.1, 2.10.1-RC1,
> > > 2.10.1-SNAPSHOT
> > > }
> >
> > isAPICompatible must be consistent across all sbt versions used for a
> > version of Scala. This means that the cross-version suffixes for Scala
> > versions 2.10 and earlier are fixed and cannot change. Consider an sbt
> > 0.12 user publishing for 2.9.2 and 2.10.0. Their cross version suffixes
> > will be _2.9.2 and _2.10. An sbt 0.13 user with the above function would
> > have suffixes of _2.9 and _2.10. Thus, they would not agree on the 2.9
> > suffix.
> >
>
> That's a good point! I haven't thought about that one. Fortunately enough,
> it's easy to fix by adding another case. I don't think having special cases
> like that is a big deal as long as we agree what to do in the future.

Eugene's updated patch reminded me that this check occurs elsewhere and doesn't need to be handled in isAPICompatible. It can just be dropped.

-Mark

[eugene yokota]

Imho it's less confusing if the semantics of M/RCs were the same for Scala and sbt versions.

API compatibility is not guaranteed on either Scala or sbt RCs, so it's probably safer to assume x.y.0-RC1 is not API compat.

To improve the build users experience,

* 0.13 could add easier way to use source deps in plugins.sbt like:

      addSbtPlugin(ref(uri("git://github.com/sbt/sbt-assembly.git#0.8.5"))) // can macro be used to extract ref upfront?

* 0.13 could change the semantics on %% and addSbtPlugin to be isAPICompatible aware, so the following works for RCs:

      addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.8.5")

Either would allow the build users to upgrade sbt 0.13.0-RC1, RC2, and final without changing their sbt files.

Plugin authors would need to keep up with 0.13.0-RCs, like the lib authors did on Scala 2.10.0 RCs.

-eugene

[Mark Harrah]

On Sat, 5 Jan 2013 22:58:48 -0500
eugene yokota <eed3...@gmail.com> wrote:

> Imho it's less confusing if the semantics of M/RCs were the same for Scala
> and sbt versions.
> API compatibility is not guaranteed on either Scala or sbt RCs, so it's
> probably safer to assume x.y.0-RC1 is not API compat.
>
> To improve the build users experience,
> * 0.13 could add easier way to use source deps in plugins.sbt like:
> addSbtPlugin(ref(uri("git://github.com/sbt/sbt-assembly.git#0.8.5")))
> // can macro be used to extract ref upfront?

Source dependencies need to be known before settings are evaluated. addSbtPlugin has no access to the Project. You will be able to define Projects in .sbt files, so it is easier in that sense.

project/plugins.sbt:

val p = Project("plugin-def", file(".")).dependsOn( uri(...) )

The Project(...) is basically boilerplate

> * 0.13 could change the semantics on %% and addSbtPlugin to be
> isAPICompatible aware, so the following works for RCs:
> addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.8.5")
>
> Either would allow the build users to upgrade sbt 0.13.0-RC1, RC2, and
> final without changing their sbt files.
>
> Plugin authors would need to keep up with 0.13.0-RCs, like the lib authors
> did on Scala 2.10.0 RCs.

That is the reason for the change to only major.minor in the first place. sbt plugin authors were the ones who wanted it. There is no need for them to keep up with RCs if they are usually binary compatible. sbt does Beta releases for .0 releases to try to make an RC really a release candidate. No one publishes plugins against milestones or Betas- perhaps they just use source dependencies or build plugins locally. If they did publish them, they'd get published to the snapshot repository, which wouldn't get pulled in for a full sbt release.

-Mark

> -eugene
>
> On Sat, Jan 5, 2013 at 11:54 AM, Mark Harrah <dmha...@gmail.com> wrote:
>
> > I think this matches what has been discussed. However, this is also used
> > for sbt, right? sbt RCs, even for .0, should be compatible because that is
> > usually the case, despite not being guaranteed.
> >
> > -Mark
>

[Grzegorz Kossakowski]

On 7 January 2013 09:20, Mark Harrah <dmha...@gmail.com> wrote:

> * 0.13 could change the semantics on %% and addSbtPlugin to be
> isAPICompatible aware, so the following works for RCs:
>       addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.8.5")
>
> Either would allow the build users to upgrade sbt 0.13.0-RC1, RC2, and
> final without changing their sbt files.
>
> Plugin authors would need to keep up with 0.13.0-RCs, like the lib authors
> did on Scala 2.10.0 RCs.

That is the reason for the change to only major.minor in the first place.  sbt plugin authors were the ones who wanted it.  There is no need for them to keep up with RCs if they are usually binary compatible.  sbt does Beta releases for .0 releases to try to make an RC really a release candidate.  No one publishes plugins against milestones or Betas- perhaps they just use source dependencies or build plugins locally.  If they did publish them, they'd get published to the snapshot repository, which wouldn't get pulled in for a full sbt release.

I think the difference between sbt plugins and Scala-based libraries is that you tend to have less of transitive dependencies between sbt plugins, right?

I'll be pushing Scala in direction of RCs being a real RCs (meaning we should have 2-3 RCs at most) but this is an ongoing process. Moreover, it's very often the case that you cannot fix a bug with binary compatibility constraints in place.

--
Grzegorz Kossakowski

[eugene yokota]

So how do we proceed?

Can we define isScalaAPICompatible and isSbtAPICompatible to distinguish the semantic difference of x.y.0-RC1 using code?

-eugene

[Grzegorz Kossakowski]

On 7 January 2013 09:20, Mark Harrah <dmha...@gmail.com> wrote:

That is the reason for the change to only major.minor in the first place.  sbt plugin authors were the ones who wanted it.  There is no need for them to keep up with RCs if they are usually binary compatible.  sbt does Beta releases for .0 releases to try to make an RC really a release candidate.  No one publishes plugins against milestones or Betas- perhaps they just use source dependencies or build plugins locally.  If they did publish them, they'd get published to the snapshot repository, which wouldn't get pulled in for a full sbt release.

As I mentioned before I'll be pushing Scala into right direction but I really think we (Scala project) need not be constrained by binary compatibility in RCs because people tend to discover rather awful bugs during that period that require non-BC change to fix. I wish the reality was different but I don't think we can expect it to change any time soon.

I agree that it would be a lot better to have consistent treatment of versions and BC for both Scala and Sbt. Can we compromise on the definition Eugene gave earlier in this thread? It seems to cover all of Scala needs at least.

--
Grzegorz Kossakowski

Scalac hacker at Typesafe

twitter: @gkossakowski

github: @gkossakowski

[Grzegorz Kossakowski]

On 5 January 2013 08:54, Mark Harrah <dmha...@gmail.com> wrote:

Eugene's updated patch reminded me that this check occurs elsewhere and doesn't need to be handled in isAPICompatible.  It can just be dropped.

Where's that? I'd like to double check if nothing is missing there.

[Grzegorz Kossakowski]

On 12 January 2013 19:13, eugene yokota <eed3...@gmail.com> wrote:

So how do we proceed?

Can we define isScalaAPICompatible and isSbtAPICompatible to distinguish the semantic difference of x.y.0-RC1 using code?

Sorry for the delay I got distracted by other things. If this is what we want then it's fine with me but it must be clearly documented. I'm working on documentation like that for Scala project (about versioning, bc, etc.).

[Paul Phillips]

On Mon, Jan 14, 2013 at 3:45 PM, Grzegorz Kossakowski <grzegorz.k...@gmail.com> wrote:

As I mentioned before I'll be pushing Scala into right direction but I really think we (Scala project) need not be constrained by binary compatibility in RCs because people tend to discover rather awful bugs during that period that require non-BC change to fix. I wish the reality was different but I don't think we can expect it to change any time soon.

I don't think it should even be up for discussion that we should be constrained by binary compatibility requirements in RCs. To say nothing of milestones.

[Mark Harrah]

On Sat, 12 Jan 2013 22:13:46 -0500
eugene yokota <eed3...@gmail.com> wrote:

> So how do we proceed?
>
> Can we define isScalaAPICompatible and isSbtAPICompatible to distinguish
> the semantic difference of x.y.0-RC1 using code?

Yes, I think so.

-Mark

[Mark Harrah]

On Mon, 14 Jan 2013 15:45:20 -0800
Grzegorz Kossakowski <grzegorz.k...@gmail.com> wrote:

> On 7 January 2013 09:20, Mark Harrah <dmha...@gmail.com> wrote:
>
> > That is the reason for the change to only major.minor in the first place.
> > sbt plugin authors were the ones who wanted it. There is no need for them
> > to keep up with RCs if they are usually binary compatible. sbt does Beta
> > releases for .0 releases to try to make an RC really a release candidate.
> > No one publishes plugins against milestones or Betas- perhaps they just
> > use source dependencies or build plugins locally. If they did publish
> > them, they'd get published to the snapshot repository, which wouldn't get
> > pulled in for a full sbt release.
> >
>
> As I mentioned before I'll be pushing Scala into right direction but I
> really think we (Scala project) need not be constrained by
> binary compatibility in RCs because people tend to discover rather awful
> bugs during that period that require non-BC change to fix. I wish the
> reality was different but I don't think we can expect it to change any time
> soon.

The quoted argument was only about sbt. It has already been accepted that Scala RCs will be handled differently.

> I agree that it would be a lot better to have consistent treatment of
> versions and BC for both Scala and Sbt. Can we compromise on the definition
> Eugene gave earlier in this thread? It seems to cover all of Scala needs at
> least.

Yes, it is fine for Scala. I don't see the need to have the same definition for sbt, though.

-Mark

> --
> Grzegorz Kossakowski
> Scalac hacker at Typesafe <http://www.typesafe.com/>
> twitter: @gkossakowski <http://twitter.com/gkossakowski>
> github: @gkossakowski <http://github.com/gkossakowski>

[Mark Harrah]

On Mon, 14 Jan 2013 15:46:21 -0800
Grzegorz Kossakowski <grzegorz.k...@gmail.com> wrote:

> On 5 January 2013 08:54, Mark Harrah <dmha...@gmail.com> wrote:
>
> >
> > Eugene's updated patch reminded me that this check occurs elsewhere and
> > doesn't need to be handled in isAPICompatible. It can just be dropped.
> >
>
> Where's that? I'd like to double check if nothing is missing there.

ivy/.../CrossVersion.scala

binaryScalaVersion and binarySbtVersion

-Mark

> --
> Grzegorz Kossakowski

[eugene yokota]

I added isSbtApiCompatible, sbtApiVersion, isScalaApiCompatible, and scalaApiVersion to #600.

Can I also rewrite binaryScalaVersion and binarySbtVersion using the new *ApiVersion methods

so scalaBinaryVersion and sbtBinaryVersion becomes full when we are dealing with limbo versions?

For example, sbt 0.13.0-SNAPSHOT's sbtBinaryVersion becomes "0.13.0-SNAPSHOT". 

-eugene

[Mark Harrah]

On Thu, 17 Jan 2013 21:51:56 -0800 (PST)
eugene yokota <eed3...@gmail.com> wrote:

> I added isSbtApiCompatible, sbtApiVersion, isScalaApiCompatible,
> and scalaApiVersion to #600.
>
> Can I also rewrite binaryScalaVersion and binarySbtVersion using the new
> *ApiVersion methods
> so scalaBinaryVersion and sbtBinaryVersion becomes full when we are dealing
> with limbo versions?
> For example, sbt 0.13.0-SNAPSHOT's sbtBinaryVersion becomes
> "0.13.0-SNAPSHOT".

Yes, I'm pretty sure you have to rewrite them or it won't be consistent.

-Mark

> -eugene
>
> On Monday, January 14, 2013 7:01:49 PM UTC-5, Mark Harrah wrote:
> >
> > On Sat, 12 Jan 2013 22:13:46 -0500
> > eugene yokota <eed3...@gmail.com <javascript:>> wrote:
> >
> > > So how do we proceed?
> > >
> > > Can we define isScalaAPICompatible and isSbtAPICompatible to distinguish
> > > the semantic difference of x.y.0-RC1 using code?
> >
> > Yes, I think so.
> >
> > -Mark
> >
> > > -eugene
> > >
> > > On Mon, Jan 7, 2013 at 1:58 PM, Grzegorz Kossakowski <

> > > grzegorz.k...@gmail.com <javascript:>> wrote:
> > >
> > > > On 7 January 2013 09:20, Mark Harrah <dmha...@gmail.com <javascript:>>

> --
> You received this message because you are subscribed to the Google Groups "simple-build-tool" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/simple-build-tool/-/RCr5U2afVX4J.

[eugene yokota]

ok. I refactored binaryVersion to take a String => Option[(Int,Int)], so binaryScalaVersion and binarySbtVersion are

aware of the new binary/full calculation. I tested 0.13.0-SNAPSHOT locally:

    > sbt-binary-version

    [info] 0.13.0-SNAPSHOT 

Here's after putting `addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.8.5")`:

[warn] module not found: com.eed3si9n#sbt-assembly;0.8.5

[warn] ==== typesafe-ivy-snapshots: tried

[warn]   http://repo.typesafe.com/typesafe/ivy-snapshots/com.eed3si9n/sbt-assembly/scala_2.10/sbt_0.13.0-SNAPSHOT/0.8.5/ivys/ivy.xml

[warn] ==== sbt-plugin-releases: tried

[warn]   http://scalasbt.artifactoryonline.com/scalasbt/sbt-plugin-releases/com.eed3si9n/sbt-assembly/scala_2.10/sbt_0.13.0-SNAPSHOT/0.8.5/ivys/ivy.xml

[warn] ==== local: tried

[warn]   /Users/eed3si9n/.ivy2/local/com.eed3si9n/sbt-assembly/scala_2.10/sbt_0.13.0-SNAPSHOT/0.8.5/ivys/ivy.xml

[warn] ==== public: tried

[warn]   http://repo1.maven.org/maven2/com/eed3si9n/sbt-assembly_2.10_0.13.0-SNAPSHOT/0.8.5/sbt-assembly-0.8.5.pom

It hitting "scala_2.10/sbt_0.13.0-SNAPSHOT" as expected. I wasn't able to build sbt-assembly without modification, so it's ok that it didn't find it.

-eugene