[0.12] plan
Mark Harrah
-Mark
Doug Tangren
Please see https://github.com/harrah/xsbt/wiki/ChangeSummary_0.12.0 for the plan for 0.12.0. The timing of the first beta depends on feedback, but could be within the next month.
-Mark
--
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.
ijuma
Mark Harrah
On Sun, 15 Jan 2012 16:51:55 -0800 (PST)
ijuma <ism...@juma.me.uk> wrote:
> Hi Mark,
>
> Thanks for sharing. Looks good. Bill Venners mentioned some improvements to
> SBT's testing support[1], are they still planned?
If there is a specific timeline for those changes, it would come from Bill. We agree on the changes to be made, but any work I put into it will be in response to his work. So yes, still planned, but I don't know when.
The last time the test interface was enhanced, it was done in a backwards compatible way. I expect the same this time and changes can probably go in without waiting for a .0 release.
-Mark
Doug Tangren
Hey Ismael,
If there is a specific timeline for those changes, it would come from Bill. We agree on the changes to be made, but any work I put into it will be in response to his work. So yes, still planned, but I don't know when.
On Sun, 15 Jan 2012 16:51:55 -0800 (PST)
ijuma <ism...@juma.me.uk> wrote:
> Hi Mark,
>
> Thanks for sharing. Looks good. Bill Venners mentioned some improvements to
> SBT's testing support[1], are they still planned?
The last time the test interface was enhanced, it was done in a backwards compatible way. I expect the same this time and changes can probably go in without waiting for a .0 release.
eugene yokota
Mark Harrah
Sometimes there are exceptions, but a full deprecation cycle should be the rule. The old style would need to have been deprecated in 0.11.0 to be removed in 0.12.0.
-Mark
> -eugene
>
Simon Ochsenreither
Would it be possible to make the 0.7 documentation less visible on Google in that timeframe?
E. g. if I search for "sbt dependency" the first three results point to the old code.google site with 0.7.
Especially to new users and people don't working with SBT every day it is hugely annoying and confusing that every SBT serach has some obsolete pages with 0.7 in it.
Could this be fixed?
Thanks!
Simon
Maxime Lévesque
+1
It has happen to me more than once, that while helping a newbie, he was mislead by info from the old site.
Simon
--
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/-/7MnX41yhdGkJ.
ijuma
If there is a specific timeline for those changes, it would come from Bill. We agree on the changes to be made, but any work I put into it will be in response to his work. So yes, still planned, but I don't know when.
Mark Harrah
Mark Harrah <dmha...@gmail.com> wrote:
> Please see https://github.com/harrah/xsbt/wiki/ChangeSummary_0.12.0 for the plan for 0.12.0. The timing of the first beta depends on feedback, but could be within the next month.
A correction to the jline point: recent Scala versions use their own jline version, so upgrading to jline 1.0 doesn't affect the Scala console for those versions.
-Mark
Mark Harrah
Mark Harrah <dmha...@gmail.com> wrote:
> Hey Ismael,
>
> On Sun, 15 Jan 2012 16:51:55 -0800 (PST)
> ijuma <ism...@juma.me.uk> wrote:
>
> > Hi Mark,
> >
> > Thanks for sharing. Looks good. Bill Venners mentioned some improvements to
> > SBT's testing support[1], are they still planned?
>
> If there is a specific timeline for those changes, it would come from Bill. We agree on the changes to be made, but any work I put into it will be in response to his work. So yes, still planned, but I don't know when.
>
> The last time the test interface was enhanced, it was done in a backwards compatible way. I expect the same this time and changes can probably go in without waiting for a .0 release.
A correction: It is likely that we will need a different interface, which will require a .0 release. I expect this interface is not used in actual builds and is probably rare even in plugins, but it will make sbt binary incompatible and hence the need to include it in a .0 release. We are seeing if this can be done for 0.12.0. I still expect to support the old interface indefinitely as before, so that older test frameworks are supported without changes.
In summary, we are aiming for 0.12.0 and in theory, users won't notice.
-Mark
> > [1] https://groups.google.com/d/msg/scalatest-users/bihrcBtP6eg/01-DTASHNT0J
> >
>
Mark Harrah
On Mon, 16 Jan 2012 06:27:18 -0800 (PST)
Simon Ochsenreither <simon.och...@googlemail.com> wrote:
> Hi,
>
> Would it be possible to make the 0.7 documentation less visible on Google
> in that timeframe?
How do you suggest fixing this?
-Mark
> E. g. if I search for "sbt dependency" the* first three results* point to
ijuma
A correction: It is likely that we will need a different interface, which will require a .0 release. I expect this interface is not used in actual builds and is probably rare even in plugins, but it will make sbt binary incompatible and hence the need to include it in a .0 release. We are seeing if this can be done for 0.12.0. I still expect to support the old interface indefinitely as before, so that older test frameworks are supported without changes.
Simon Ochsenreither
Robots.txt would be a god way to start. If that doesn't help or isn't possible, delete it. Better: Delete the whole Google Code stuff. If there is something important, move it to the current site.
It is doing more harm than good since a long time already. Getting rid of the "x" in "xsbt" would be a good idea, too. One character of difference is relevant enough in a three-letter project name to cause confusion, especially if it is at the beginning of the name and not at the end.
Simon
Josh Suereth
Simon
--
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/-/diz0Cai6-qwJ.
Mark Harrah
Mark Harrah <dmha...@gmail.com> wrote:
> Please see https://github.com/harrah/xsbt/wiki/ChangeSummary_0.12.0 for the plan for 0.12.0. The timing of the first beta depends on feedback, but could be within the next month.
I worked on cross versioning some more. You can see the modified summary in the above ChangeSummary under Pending and the latest changes on the 0.12 branch.
I have to wonder if having cross versioning is worth it any more. I realize this isn't an exciting topic to read about, think about, and discuss (it isn't exciting to work on either if it makes you feel any better), but please read the above summary, the following explanation, and provide your opinion.
By cross versioning, I mean the practice of including some part of the Scala version in the module ID to distinguish an artifact generated by compiling the same source code against different Scala versions. I do not mean the ability to build against multiple Scala versions using +task, which will stay; I am just referring to the cross version convention.
There are now two ideas of Scala versions:
1. the full version, like 2.10.0-M1
2. the binary version, like 2.10
However, in the case of 2.10.0-M1, the published artifact shouldn't use 2.10, but rather the full 2.10.0-M1 because binary compatibility isn't guaranteed and we don't want to contaminate the binary compatible pool. Dependencies should use 2.10, though, because binary compatibility is likely (this would matter more for building against a 2.10.1-M1, where artifacts built against 2.10.0 exist and should probably be used). However, other projects compiling against 2.10.0-M1 have to explicitly say:
"a" % "b" % "1.0" cross CrossVersion.full
in order to get a project built against 2.10.0-M1. This gets more complicated when mixed with features added for flexibility, such as being able to specify a String => String function to remap the Scala version (such as to use a dependency published against 2.9.0 when building against 2.9.1 because it wasn't published against 2.9.1). As a counterpoint, I expect this feature would be used less with binary compatibility within a minor version.
The usual disadvantages from before binary compatibility apply, such as Maven not recognizing that name_2.10 and name_2.11 are the same underlying module and should generate a conflict.
It has always been a hack to encode this in the inflexible pom.xml format and I think it may be best to move away from this for projects built against Scala 2.10 and later. However, perhaps this is better than any ad hoc solutions that might take its place. I don't see users of other build tools doing this, so I expect nothing would replace it.
If you are able to use Ivy metadata, you are probably already capable of solving this problem better with extra attributes (as sbt does now). Most open source users probably publish poms, though. All in all, it seems to me like too much work for the provided benefit, but I'm open to opinions either way.
Thanks,
Mark
Mark Harrah
Simon Ochsenreither <simon.och...@googlemail.com> wrote:
> Hi Mark!
>
> Robots.txt would be a god way to start.
This is a good idea and I looked into it. Unfortunately, I don't control code.google.com/robots.txt (obviously) and I can't generate <meta> tags on the wiki pages (Google automatically generates <meta name="ROBOTS" content="NOARCHIVE"> but that can't be configured).
> If that doesn't help or isn't
> possible, delete it. Better: Delete the whole Google Code stuff. If there
> is something important, move it to the current site.
I don't think this is fair to users. It hasn't even been a year since 0.10.0 was released. Google Code provides archives of previous releases, the source code, and the documentation. Last I checked, the wiki format still wasn't open, so that would require work to move somewhere.
I understand it is a problem that it is still around, but I don't think deleting the project or the wiki pages are net benefits. Josh's suggestion seems to be a decent next step to try.
> It is doing more harm than good since a long time already. Getting rid of
> the "x" in "xsbt" would be a good idea, too. One character of difference is
> relevant enough in a three-letter project name to cause confusion,
> especially if it is at the beginning of the name and not at the end.
I understand, but changing that will invalidate links and probably hurt search results in the short term (but I'm just guessing about search results). However, perhaps this can be done in the way Josh suggests.
-Mark
> Simon
>
Mark Harrah
Mark Harrah <dmha...@gmail.com> wrote:
> Please see https://github.com/harrah/xsbt/wiki/ChangeSummary_0.12.0 for the plan for 0.12.0. The timing of the first beta depends on feedback, but could be within the next month.
scala-tools.org has been dropped as a default repository from the 0.12 branch because it is likely that by the time 0.13.0 comes out, scala-tools.org will be gone. I have also renamed sbt's organization from org.scala-tools.sbt to org.scala-sbt. Sorry for any inconvenience this will cause, but obviously I don't have control over this.
Thanks,
Mark
eugene yokota
> I have to wonder if having cross versioning is worth it any more. I realize this isn't an exciting topic to read about, think about, and discuss
I think it's a fun topic. If this works out && Scala keeps its binary
compat across revisions, library authors don't have to rush to cross
publish every time a minor release comes out.
> By cross versioning, I mean the practice of including some part of the Scala version in the module ID to distinguish an artifact generated by compiling the same source code against different Scala versions. I do not mean the ability to build against multiple Scala versions using +task, which will stay; I am just referring to the cross version convention.
Aren't they related?
If I cross publish 2.10.0 and 2.10.1, the second publish would fail
because lib_2.10 is already published. In that case, maybe 2.10.0
should be skipped.
> There are now two ideas of Scala versions:
>
> 1. the full version, like 2.10.0-M1
> 2. the binary version, like 2.10
The term "binary version" is confusing to me.
The version of the binary (jar) is the version of the jar.
I think it's better to use some other term like "contract version",
"signature version", "API version", "header version", "bundle
interface version", etc..
> However, in the case of 2.10.0-M1, the published artifact shouldn't use 2.10, but rather the full 2.10.0-M1 because binary compatibility isn't guaranteed and we don't want to contaminate the binary compatible pool.
To clarify, you mean that the artifact name becomes "b_2.10.0-M1" here
instead of "b_2.10"?
> Dependencies should use 2.10, though, because binary compatibility is likely (this would matter more for building against a 2.10.1-M1, where artifacts built against 2.10.0 exist and should probably be used). However, other projects compiling against 2.10.0-M1 have to explicitly say:
>
> "a" % "b" % "1.0" cross CrossVersion.full
>
> in order to get a project built against 2.10.0-M1.
Do you think it would be too confusing if there were
CrossVersion.both, which first checked the full version before
checking the binary version (and %% used CrossVersion.both)? If so, I
can just say
scalaVersion := "2.10.0-M1"
libraryDependencies += "a" %% "b" % "1.0"
This also would free build users from remembering which library
publishes using full instead of binary version.
> I expect this feature would be used less with binary compatibility within a minor version.
While that may be true eventually, I expect the upgrade adoptions to
be slow, especially for those using sbt 0.10 at work.
> It has always been a hack to encode this in the inflexible pom.xml format and I think it may be best to move away from this for projects built against Scala 2.10 and later. However, perhaps this is better than any ad hoc solutions that might take its place.
The alternative would be that the library versions gets hardcoded to a
particular version of Scala and up, which you see often with Ruby apps
etc. That would not be good.
> Most open source users probably publish poms, though.
As long as we publish to Maven repos, pom seems like a good nice-to-have.
-eugene
Daniel Sobral
> On Sun, 15 Jan 2012 18:24:25 -0500
> Mark Harrah <dmha...@gmail.com> wrote:
>
>> Please see https://github.com/harrah/xsbt/wiki/ChangeSummary_0.12.0 for the plan for 0.12.0. The timing of the first beta depends on feedback, but could be within the next month.
>
> I worked on cross versioning some more. You can see the modified summary in the above ChangeSummary under Pending and the latest changes on the 0.12 branch.
>
> I have to wonder if having cross versioning is worth it any more. I realize this isn't an exciting topic to read about, think about, and discuss (it isn't exciting to work on either if it makes you feel any better), but please read the above summary, the following explanation, and provide your opinion.
>
> By cross versioning, I mean the practice of including some part of the Scala version in the module ID to distinguish an artifact generated by compiling the same source code against different Scala versions. I do not mean the ability to build against multiple Scala versions using +task, which will stay; I am just referring to the cross version convention.
>
> There are now two ideas of Scala versions:
>
> 1. the full version, like 2.10.0-M1
> 2. the binary version, like 2.10
>
> However, in the case of 2.10.0-M1, the published artifact shouldn't use 2.10, but rather the full 2.10.0-M1 because binary compatibility isn't guaranteed and we don't want to contaminate the binary compatible pool. Dependencies should use 2.10, though, because binary compatibility is likely (this would matter more for building against a 2.10.1-M1, where artifacts built against 2.10.0 exist and should probably be used). However, other projects compiling against 2.10.0-M1 have to explicitly say:
I don't understand the issues well here, and I do like the ease which
"%%" brings to library use. As for the specific case above, however,
milestone releases are not meant for general distribution, but for
general evaluation. As such, I don't think any effort should be wasted
in making their use easier -- one can always fully specify the version
with "%", after all. Right?
I fear I might be missing the point here, but this seems important
enough to merit the effort of trying to, so, if I'm in error, please
try again to explain. Maybe the caffeine will have had time to work
its effects the next time! :-)
--
Daniel C. Sobral
I travel to the future all the time.
Mark Harrah
Daniel Sobral <dcso...@gmail.com> wrote:
> > By cross versioning, I mean the practice of including some part of the Scala version in the module ID to distinguish an artifact generated by compiling the same source code against different Scala versions. I do not mean the ability to build against multiple Scala versions using +task, which will stay; I am just referring to the cross version convention.
> >
> > There are now two ideas of Scala versions:
> >
> > 1. the full version, like 2.10.0-M1
> > 2. the binary version, like 2.10
> >
> > However, in the case of 2.10.0-M1, the published artifact shouldn't use 2.10, but rather the full 2.10.0-M1 because binary compatibility isn't guaranteed and we don't want to contaminate the binary compatible pool. Dependencies should use 2.10, though, because binary compatibility is likely (this would matter more for building against a 2.10.1-M1, where artifacts built against 2.10.0 exist and should probably be used). However, other projects compiling against 2.10.0-M1 have to explicitly say:
>
> I don't understand the issues well here, and I do like the ease which
> "%%" brings to library use. As for the specific case above, however,
> milestone releases are not meant for general distribution, but for
> general evaluation. As such, I don't think any effort should be wasted
> in making their use easier -- one can always fully specify the version
> with "%", after all. Right?
Yes, I would agree, but historically, milestone users still complain. It is true that in the common case, it should just work, but there is more to consider in the general case.
You don't have to ever write the version (like name_2.10.0-M1), you say:
"a" % "b" % "1.0" cross CrossVersion.full
to use the full version instead of the ABI version.
> I fear I might be missing the point here, but this seems important
> enough to merit the effort of trying to, so, if I'm in error, please
> try again to explain. Maybe the caffeine will have had time to work
> its effects the next time! :-)
I think you have it right. The biggest problem is milestone releases may require users to do manual tweaking, but this is only when building against other software using milestone releases.
-Mark
Mark Harrah
eugene yokota <eed3...@gmail.com> wrote:
> On Sun, Jan 22, 2012 at 11:00 PM, Mark Harrah <dmha...@gmail.com> wrote:
> > I have to wonder if having cross versioning is worth it any more. I realize this isn't an exciting topic to read about, think about, and discuss
>
> I think it's a fun topic. If this works out && Scala keeps its binary
> compat across revisions, library authors don't have to rush to cross
> publish every time a minor release comes out.
>
> > By cross versioning, I mean the practice of including some part of the Scala version in the module ID to distinguish an artifact generated by compiling the same source code against different Scala versions. I do not mean the ability to build against multiple Scala versions using +task, which will stay; I am just referring to the cross version convention.
>
> Aren't they related?
> If I cross publish 2.10.0 and 2.10.1, the second publish would fail
> because lib_2.10 is already published. In that case, maybe 2.10.0
> should be skipped.
Yes, they are related, but you wouldn't cross publish against binary compatible releases.
> > There are now two ideas of Scala versions:
> >
> > 1. the full version, like 2.10.0-M1
> > 2. the binary version, like 2.10
>
> The term "binary version" is confusing to me.
> The version of the binary (jar) is the version of the jar.
> I think it's better to use some other term like "contract version",
> "signature version", "API version", "header version", "bundle
> interface version", etc..
Yes, it is short for application binary interface (ABI) version.
> > However, in the case of 2.10.0-M1, the published artifact shouldn't use 2.10, but rather the full 2.10.0-M1 because binary compatibility isn't guaranteed and we don't want to contaminate the binary compatible pool.
>
> To clarify, you mean that the artifact name becomes "b_2.10.0-M1" here
> instead of "b_2.10"?
Yes.
> > Dependencies should use 2.10, though, because binary compatibility is likely (this would matter more for building against a 2.10.1-M1, where artifacts built against 2.10.0 exist and should probably be used). However, other projects compiling against 2.10.0-M1 have to explicitly say:
> >
> > "a" % "b" % "1.0" cross CrossVersion.full
> >
> > in order to get a project built against 2.10.0-M1.
>
> Do you think it would be too confusing if there were
> CrossVersion.both, which first checked the full version before
> checking the binary version (and %% used CrossVersion.both)? If so, I
> can just say
>
> scalaVersion := "2.10.0-M1"
>
> libraryDependencies += "a" %% "b" % "1.0"
>
> This also would free build users from remembering which library
> publishes using full instead of binary version.
This is similar to previous suggestions to look for a fallback. This is essentially a dynamic revision and can't be standard practice as discussed previously (mainly, build reproducibility). I don't think this being for milestone releases affects this.
> > I expect this feature would be used less with binary compatibility within a minor version.
>
> While that may be true eventually, I expect the upgrade adoptions to
> be slow, especially for those using sbt 0.10 at work.
I'm not sure what you mean here, but something will change for Scala 2.10 in sbt 0.12. In order to support the new name_2.10 style, you have to use 0.12 or do it manually.
> > It has always been a hack to encode this in the inflexible pom.xml format and I think it may be best to move away from this for projects built against Scala 2.10 and later. However, perhaps this is better than any ad hoc solutions that might take its place.
>
> The alternative would be that the library versions gets hardcoded to a
> particular version of Scala and up, which you see often with Ruby apps
> etc. That would not be good.
This is already what ScalaTest does (did?), even though cross building exists.
-Mark
eugene yokota
>> > I expect this feature would be used less with binary compatibility within a minor version.
>>
>> While that may be true eventually, I expect the upgrade adoptions to
>> be slow, especially for those using sbt 0.10 at work.
>
> I'm not sure what you mean here, but something will change for Scala 2.10 in sbt 0.12. In order to support the new name_2.10 style, you have to use 0.12 or do it manually.
I like jumping on to new sbt versions, but we can't expect all
libraries to go to sbt 0.12 immediately.
Here's a scenario. A popular project is stuck at sbt 0.10/0.11 for
corporate policy or lack of a plugin, and it publishes against Scala
2.10.0 using name_2.10.0 style.
If the libraries users too are also on sbt 0.11, everything works out.
But suppose some users decide to give sbt 0.12 a try.
libraryDependencies += "com.big" %% "name" % "2.0"
They'll get error "name_2.10" was not resolved. This guy would
complain to the library and might come to conclusion that %% was
broken if he has to scalaVersion match {..} just to cross compile, or
revert back to sbt 0.11.
> This is similar to previous suggestions to look for a fallback. This is essentially a dynamic revision and can't be standard practice as discussed previously (mainly, build reproducibility). I don't think this being for milestone releases affects this.
If someone wants to avoid the dynamic nature, they can use %,
CrossVersion.full, or CrossVersion.binary. I thought it's a good
tradeoff, but now I am not sure.
-eugene
Josh Suereth
A few points:
Mark
--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
Mark Harrah
Josh Suereth <joshua....@gmail.com> wrote:
> I like the ideas behind the new binary compatibility concerns.
>
> A few points:
>
> (1) Never drop Maven support (pushing poms, maven style). The minute we
> do, we alienate a lot of potential users and enter our own hole of
> existence. I'd rather see every scala project on maven central and force
> them to recognize the limiting issues of poms in there. We have enough
> projects, I think they'll take notice soon if we all start pushing to
> central.
No one is suggesting dropping pom support. It is only about dropping cross-versioning support because of the limitations of poms.
> (2) Love the custom function idea. This is beautiful. Sometimes, you're
> using such a subset of a library, that you remain binary compatible with
> newer versions even if the library is not "universally" binary compatible
> with a previous version.
This was added by Indrajit in 0.11.0 I think.
> (3) What do you think of potentially altering the current convention of
> adding the scala library to the module name and instead add it to the
> beginning of the organization. This would lead to pushing things onto
> maven central in the following directory structure:
>
> scala/2/9/com/jsuereth/
> pgp-library/
> 0.5/
> pgp-library-05.jar
> ...
>
> This means SBT can add the "base" directory and use cross versioning to
> pull in 2.9.x artifacts. However, you *could* also add a repository like
> so:
>
> "foo 2.9" at "http://foo.com/repo/scala/2/9"
>
> And you would get *just* 2.9 artifacts using the basic identifiers. It
> gives us a lot more niceties than appending the scala version to the name.
> It's kind of like namespacing repositories by version in YUM/Debian.
>
> Note: Idea adapted from Havoc's idea of universes. Also, Sonatype would
> let us publish to maven-central if our POMs matched this format.
Sounds interesting on the surface. I will think about it some more.
-Mark
Mark Harrah
eugene yokota <eed3...@gmail.com> wrote:
> On Mon, Jan 23, 2012 at 9:29 AM, Mark Harrah <dmha...@gmail.com> wrote:
> >> > I expect this feature would be used less with binary compatibility within a minor version.
> >>
> >> While that may be true eventually, I expect the upgrade adoptions to
> >> be slow, especially for those using sbt 0.10 at work.
> >
> > I'm not sure what you mean here, but something will change for Scala 2.10 in sbt 0.12. In order to support the new name_2.10 style, you have to use 0.12 or do it manually.
>
> I like jumping on to new sbt versions, but we can't expect all
> libraries to go to sbt 0.12 immediately.
>
> Here's a scenario. A popular project is stuck at sbt 0.10/0.11 for
> corporate policy or lack of a plugin, and it publishes against Scala
> 2.10.0 using name_2.10.0 style.
> If the libraries users too are also on sbt 0.11, everything works out.
> But suppose some users decide to give sbt 0.12 a try.
>
> libraryDependencies += "com.big" %% "name" % "2.0"
>
> They'll get error "name_2.10" was not resolved. This guy would
> complain to the library and might come to conclusion that %% was
> broken if he has to scalaVersion match {..} just to cross compile, or
> revert back to sbt 0.11.
There isn't an alternative. Automatically detecting the cross-version scheme using dynamic revisions is fragile, a lot of work, unreliable, and leads to unreproducible builds. It simply isn't an option. If changing the scheme to the ABI version is considered impractical, it just won't change or we will migrate away from it by having cross-versioning of the published artifact be disabled by default when building against 2.10 and later (you could still use %%).
The change has to happen across all open source projects. Consuming dependencies isn't affected that much; publishing is what matters the most. I don't think it is avoidable or reversible, which is why I have waited to be very sure Scala is binary compatible within minor versions. It is why this discussion is happening: changing this against again is not really practical, and why I have emphasized a full release cycle for 0.12.0: it needs to be reasonable to migrate to without serious regressions.
> > This is similar to previous suggestions to look for a fallback. This is essentially a dynamic revision and can't be standard practice as discussed previously (mainly, build reproducibility). I don't think this being for milestone releases affects this.
>
> If someone wants to avoid the dynamic nature, they can use %,
> CrossVersion.full, or CrossVersion.binary. I thought it's a good
> tradeoff, but now I am not sure.
Dynamic revisions can never be the default and cannot be a standard practice.
-Mark
Mark Harrah
Josh Suereth <joshua....@gmail.com> wrote:
I don't think this actually works cleanly. The pom would say the organization is scala.2.9.xyz. You would have to use this organization to resolve the module- you can't just use xyz because it is inconsistent. This means that the scala.2.9 would be appended to the repository base and you'd end up with scala/2/9.
Does the version even have to be included in the organization? Can users just declare http://foo.com/repo/scala/2/9 as the new scala-tools.org? Or, does Nexus not like this?
-Mark
Mark McBride
similar at my last company to manage maven dependencies that depended
on native code. A set of "profiles" were set up, each of which pointed
to an architecture specific repo (e.g. nexus/linux/x86_64). At build
time, a profile was activated based on arch system properties. Seems
like a similar scheme could work here, although it greatly complicates
publishing. People either have to manage a (potentially) broad set of
scala versioned repos, or publish to a central system that does so.
FWIW at Twitter we've given up on the cross publishing thing, and we
just snap a major rev when we run into incompatibilities, e.g. ostrich
4.x is 2.8.1 and will always be 2.8.1. Ostrich 1.x is 2.7.7 and will
always be so.
---Mark