update README for 0.10.0

README.md

@@ -1,34 +1,29 @@
-[Google Code project]: http://code.google.com/p/simple-build-tool
+[Google Code]: http://code.google.com/p/simple-build-tool
 [Northeast Scala Symposium]: http://www.nescala.org/2011/
 [documentation]: https://github.com/harrah/xsbt/wiki
 [Setup]: https://github.com/harrah/xsbt/wiki/Setup
 [video of a demo]: http://vimeo.com/20263617
 
-# sbt 0.9
+# sbt 0.10
 
-This is the 0.9.x development series of sbt.  See [Setup] for getting started with the latest binary release or see below to build from source.
+This is the 0.10.x series of sbt.  See [Setup] for getting started with the latest binary release or see below to build from source.
 
-The current stable release of sbt is 0.7.7, which can be downloaded from the [Google Code project].
+The previous stable release of sbt was 0.7.7, which was hosted on [Google Code].
 
-There is a [video of a demo] given at the [Northeast Scala Symposium] that gives a brief introduction to ideas in sbt 0.9.  Note that the demo was based on 0.9.0 and things have changed since then.  See the [documentation] for current information.
+There is a [video of a demo] given at the [Northeast Scala Symposium] that gives a brief introduction to the concepts in sbt 0.9 and later.  Note that the demo was based on 0.9.0 and things have changed since then.  See the [documentation] for current information.
 
 # Build from source
 
 To build from source, get the latest stable version of sbt (above) and get the code.
 
-	$ git clone -n git://github.com/harrah/xsbt.git
+	$ git clone git://github.com/harrah/xsbt.git
 	$ cd xsbt
 
-The '-n' option is strictly only necessary when using msysgit on Windows.
-(This works around an issue with spaces in the 'master' branch by not checking the 'master' branch out initially.)
+The initial branch is the development branch 0.10, which contains the latest code for the 0.10.x series.
 
-The latest tag for 0.9.x is 0.9.10:
+The latest tag for 0.10.x is 0.10.0:
 
-	$ git checkout v0.9.10
-
-Or, get the development branch for 0.9.x:
-
-	$ git checkout 0.9
+	$ git checkout v0.10.0
 
 To build:
 
@@ -36,8 +31,8 @@ To build:
 
 Copy your stable ~/bin/sbt script to ~/bin/xsbt and change it to use the launcher at:
 
-	<xsbt>/target/sbt-launch-0.9.10.jar
+	<xsbt>/target/sbt-launch-0.10.0.jar
 
-If using the 0.9 development branch, the launcher is at:
+If using the 0.10 development branch, the launcher is at:
 
-	<xsbt>/target/sbt-launch-0.10.0-SNAPSHOT.jar
+	<xsbt>/target/sbt-launch-0.10.1-SNAPSHOT.jar

notes

@@ -1,62 +0,0 @@
-Issues moving Launcher to 2.8:
-  creating an Array requires a Manifest, which brings in 40k of classes in scala.reflect
-  scala.package$ is 3k (import scala.collection.immutable.List) and brings in scala.xml
-  RichInt 2k. scala.collection.mutable.StringBuilder.ensureCapacity uses it (max), which is needed for string concat
-  scala.xml brings in 50k of classes
-  scala.math brought in 30k, can't remove because RichInt apparently uses it
-  100k additional size adds 50ms to startup time (on my faster machine)
-  difference between classpaths a) just launcher jar b) current directory + launcher jar is that b) is 50 ms slower than a)
-  was able to return to old size by enabling optimize/obfuscate phases of ProGuard
-
-- script tasks (in 'scripts' branch).  To use:
- 1) add implementation of jsr223 to project/build/lib, declare in project/plugins, or add to sbt startup classpath
- 2) Mix sbt.scripts.Scripts into your project definition
- 3) Create project/scripts/name.ext
- 4) Run as 'name'
- 5) To work with dependencies, get the task from the scriptedTasks map by name.  Ex:
-   lazy val myTask = task { ... } dependsOn scriptedTasks("myscript").
-
- - added experimental 'sbt-update version [output.jar]' command enabled by mixing in UpdateSbt trait.  It probably doesn't work on Windows, but confirmation either way would be helpful.
-  Changes 'sbt.version' after verifying the version is valid by downloading that version of sbt.
-  Updates the current launcher jar or the location specified in the second argument with either a downloaded sbt-launch-<version>.jar if available or a copy of the current launcher jar that uses <version> by default when starting new projects.
-
-TODO:
- - tasks as promises
- - aggressive recompilation
- - API API.  Read, write, search API.
- - source build system
-
- - launcher interface versioning
- - allow comments in datatype definition file
- - tests for API extractor
- - have background triggered commands (~sync)
-
-Task engine
-- method tasks will be normal tasks that pull the command line from a CommandLine task
-- per task configuration, including logging (e.g. 'task compile log debug')
-- unnamed tasks log to parent task
-- better control over parallel logging.  Approach undecided. Some possibilities:
-  + optionally one task always logging
-  + log each task to a file
-  + interactive control over logging (might require tasks that use console to be explicit in their dependence on the console)
-
-- should be able to connect one preprocessor to another
-
-- Interfaces subproject that depends on no other project and defines interfaces in package xsbti.  They are written in Java and cannot refer to Scala classes (compileOrder = JavaThenScala).  These interfaces can be used to pass objects across ClassLoader boundaries.
-- launcher/main interface is not static (no system properties should be used past the static entry point)
-- simple, well-defined ClassLoaders
-- use Exceptions instead of Option/Either
-- every component gets its own subproject
-- can use any version of compiler/Scala that is source compatible with the compiler-interface component
-- build xsbt using normal cross-build conventions
-- compiler: raw interface (no dependency analysis, but still in same jvm) or with dependency analysis
-- compiler: can specify scala-library.jar and scala-compiler.jar + version instead of retrieving the ClassLoader
-- compiler: new phase that extracts API defined in sources (classes, their members, and all type information)
-- minimal dependence on main xsbt logger from subcomponents: use thin interface for subcomponents
-
-Dependency Management
-- resolvers are completely defined in project definition (use Resolver.withDefaultResolvers)
-- configurations completely defined within project (use ModuleConfiguration.configurations)
-
-Launcher
-- see launch.specification