Skip to content

ChangeSummary_0.12.0

Jump to bottom
harrah edited this page Jan 15, 2012 · 28 revisions

Plan for 0.12.0

These are the main proposed changes for 0.12.0. Please use the mailing list for discussion.

Because of the changes involved, the 0.12.0 release requires a full release cycle, starting with a beta release. An RC out for two weeks without regressions will become 0.12.0. In addition to whether any of the listed changes should be modified or excluded altogether, an important decision is whether to release 0.12.0 against 2.9 or wait for 2.10. Please see the discussion on cross building for details.

Cross building

The cross version suffix is shortened to only include the major and minor version for Scala versions starting with the 2.10 series and for sbt versions starting with the 0.12 series. For example, sbinary_2.10 for a normal library or sbt-plugin_2.10_0.12 for an sbt plugin. This requires forward and backward binary compatibility across incremental releases for both Scala and sbt.

  1. This change has been a long time coming, but it requires everyone publishing an open source project to switch to 0.12 to publish for 2.10 or adjust the cross versioned prefix in their builds appropriately.
  2. Obviously, using 0.12 to publish a library for 2.10 requires 0.12.0 to be released before projects publish for 2.10.
  3. At the same time, sbt 0.12.0 itself should be published against 2.10.0 or else it will be stuck in 2.9.x for the 0.12.x series.

Plugin configuration directory

In 0.11.0, plugin configuration moved from project/plugins/ to just project/, with project/plugins/ being deprecated. Only 0.11.2 had a deprecation message, but in all of 0.11.x, the presence of the old style project/plugins/ directory took precedence over the new style. In 0.12.0, the new style takes precedence. Support for the old style won't be removed until 0.13.0.

  1. Ideally, a project should ensure there is never a conflict. Both styles are still supported, only the behavior when there is a conflict has changed.
  2. In practice, switching from an older branch of a project to a new branch would often leave an empty project/plugins/ directory that would cause the old style to be used, despite there being no configuration there.
  3. Therefore, the intention is that this change is strictly an improvement for projects transitioning to the new style and isn't noticed by other projects.

JLine

Move to jline 1.0. This is a (relatively) recent release that fixes several outstanding issues with jline but, as far as I can tell, remains binary compatible with 0.9.94, the version previously used. In particular:

  1. Properly closes streams when forking stty on unix.
  2. Delete key works on linux. Please check that this works for your environment as well.
  3. Line wrapping seems correct.
  4. These fixes should apply to both the sbt prompt as well as the Scala REPL.

Parsing task axis

There is an important change related to parsing the task axis for settings and tasks that fixes #202

  1. The syntax before 0.12 has been {build}project/config:key(for task)
  2. The proposed (and implemented) change for 0.12 is {build}project/config:task::key
  3. By moving the task axis before the key, it allows for easier discovery (via tab completion) of keys in plugins.
  4. It is not planned to support the old syntax. It would be ideal to deprecate it first, but this would take too much time to implement.

Aggregation

Aggregation has been made more flexible. This is along the direction that has been previously discussed on the mailing list.

  1. Before 0.12, a setting was parsed according to the current project and only the exact setting parsed was aggregated.
  2. Also, tab completion did not account for aggregation.
  3. This meant that if the setting/task didn't exist on the current project, parsing failed even if an aggregated project contained the setting/task.
  4. Additionally, if compile:package existed for the current project, *:package existed for an aggregated project, and the user requested 'package' run (without specifying the configuration) *:package wouldn't be run on the aggregated project (it isn't the same as the compile:package key that existed on the current).
  5. In 0.12, both of these situations result in the aggregated settings being selected. For example, 1. Consider a project root that aggregates a subproject sub. 2. root defines *:package. 3. sub defines compile:package and compile:compile. 4. Running root/package will run root/*:package and sub/compile:package 5. Running root/compile will run sub/compile:compile
  6. This change depends on the change to parsing the task axis.

Parallel Execution

Fine control over parallel execution is supported as described here: https://github.com/harrah/xsbt/wiki/Parallel-Execution

  1. The default behavior should be the same as before, including the parallelExecution settings.
  2. The new capabilities of the system should otherwise be considered experimental.
  3. Therefore, parallelExecution won't be deprecated at this time.
Clone this wiki locally