downgrade sbt-native-packager to 0.6.4 #162
Conversation
this restores the 2.11.7 status quo for the 2.11.8 release. the upgrade turned out to be way too problematic. even after multiple PRs addressing regressions, new ones continue to turn up; see scala/scala-dev#92 for details on the latest regressions. for past history (including details on regressions), see these PRs in this repo: scala#159, scala#157, scala#156, scala#155, scala#154, scala#142, plus issue so what's next after this? - we could maybe still consider upgrading for 2.11.9, but someone would need to thoroughly QA it on all platforms and assure us there are no regressions - or we could restrict the upgrade to 2.12.x and hope for partially crowdsourced QA so that regressions would be caught during the milestone and release candidate phases. I lean towards leaving 2.11.x frozen at 0.6.4, at least unless the upgrade brings concrete benefits to end users (no one has listed any, to my knowledge). if this is mainly just dogfooding, then 2.12.x is a better context for that.
|
@SethTisue sorry for the inconvenience :( |
np, none of the work is wasted if we can get it into 2.12 instead |
SethTisue
force-pushed
the
native-packager-downgrade
branch
from
f36a5cd to
23d097e
Compare
|
@SethTisue off-topic: do we have to change the vendor for sbt-native-packager as well? |
@muuki88 is there a reason not to? I don't know what implications the vendor setting has, I just sort of assumed it was a string that might show up in UIs somewhere |
|
sorry, by vendor I meant the artifact groupid ( |
|
well, in general, the thinking at Lightbend is that there's no big rush to make but sbt stuff specifically, I don't know, you'd have to ask the sbt folks |
downgrade sbt-native-packager to 0.6.4
this restores the 2.11.7 status quo for the 2.11.8 release.
see commit comments for further details
review by @adriaanm, cc @muuki88