Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sbt version revert to 1.2.8 #67

Merged
merged 1 commit into from
Oct 23, 2019
Merged

Sbt version revert to 1.2.8 #67

merged 1 commit into from
Oct 23, 2019

Conversation

poslegm
Copy link
Collaborator

@poslegm poslegm commented Oct 22, 2019

Unfortunately we can't update sbt version without breaking compatibility.
sbt-scalafmt v2.2.0 can't work in projects with sbt v1.2.x and older because sbt 1.3.x isn't compatible with sbt 1.2.x.

So I think we should stay on 1.2.8 as long as possible 😞

@poslegm poslegm requested a review from tanishiking October 22, 2019 23:00
Copy link
Member

@tanishiking tanishiking left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thank you for fixing it sbt/sbt#5049
I gonna kick start sbt-scalafmt 2.2.1 after CI passed

@tanishiking tanishiking merged commit 0423efc into master Oct 23, 2019
@tanishiking tanishiking deleted the sbt-revert branch October 23, 2019 06:31
@dwijnand
Copy link

sbt 1.3.x isn't compatible with sbt 1.2.x

To be clear: sbt 1.3.x is compatible with sbt 1.2.x, the way "compatible" is normally meant: backwards binary compatible. The compatibility you refer to is forward compatibility: sbt 1.2.x isn't forwards binary compatible with plugins built with sbt 1.3.x.

This isn't new: like all projects new APIs are introduced in new minor versions, making the released version non-forward compatible (scala-library is the exception here, to the detriment of its evolution outside of internal implementation details). What's new is there was a specific change in sbt 1.3 that made it extremely easy to trigger (adding an implicit to the sbt package object).

@anilkumarmyla
Copy link

Interested to know which projects are still behind on sbt 1.2.x that require this downgrade? I think in the best of interest as a community we should ensure everyone uses the latest software. A lot of work goes into improving a software and releasing a version that is much better than the previous one (in this case sbt-1.3.x). Bumping sbt version to 1.3.x in all the community plugins is a sure way to organically increase this adoption.

Another way is to build the plugin with both sbt-1.2.x & sbt-1.3.x and publish with only one of them or both (in versions that differ in major/minor versions)

@poslegm
Copy link
Collaborator Author

poslegm commented Oct 23, 2019

@anilkumarmyla There are a lot projects with sbt 1.2.x and older :)

I agree that we should motivate community to upgrade their software. But in my opinion 400 LOC formatting plugin shouldn't force users to update entire build system.

There is a possibility to update sbt for us without breaking compatibility sbt/sbt#5049 (comment). I will try to do it.

@dwijnand
Copy link

But in my opinion 400 LOC formatting plugin shouldn't force users to update entire build system.

Updating sbt version isn't hard. Users that can't do that can equally stay on older versions of this plugin.

@solarmosaic-kflorence
Copy link

FWIW I think it's pretty reasonable to force SBT upgrades when doing major version updates on plugins.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants