From 5830d9f86b2a3d5fbf27d3dfe083d5a031a1a37f Mon Sep 17 00:00:00 2001 From: Josh Soref Date: Wed, 30 Oct 2013 10:39:55 -0400 Subject: [PATCH] Improving Release note text --- release_notes/20rc1.md | 51 +++++++++++++++++++------------------ release_notes/20rc3.md | 51 +++++++++++++++++++------------------ release_notes/20rc5.md | 57 ++++++++++++++++++++++-------------------- 3 files changed, 84 insertions(+), 75 deletions(-) diff --git a/release_notes/20rc1.md b/release_notes/20rc1.md index a4b7275a..d04950a3 100644 --- a/release_notes/20rc1.md +++ b/release_notes/20rc1.md @@ -12,28 +12,28 @@ These changes have breaking interface changes and are not backwards compatible w * New syntax for spies * New interface for reporters * Better Equality testing -* Easier custom matchers +* Replaced custom matchers for ease of use * Change to `toThrow` matcher ### New syntax for asynchronous specs -Similar to [Mocha][mocha], Jasmine befores, specs, and afters can take an optional "done" callback in order to force asynchronous tests. The next function, whether it's a before, spec or after, will wait until this function is called or if a timeout is reached. +Similar to [Mocha][mocha], Jasmine `before`s, `spec`s, and `after`s can take an optional `done` callback in order to force asynchronous tests. The next function, whether it's a `before`, `spec` or `after`, will wait until this function is called or until a timeout is reached. ### New syntax for spies -Spies have a slightly modified syntax. The ideas came from a desire to preserve any of the properties on a spied-upon function and some better testing patterns. +Spies have a slightly modified syntax. The idea came from a desire to preserve any of the properties on a spied-upon function and some better testing patterns. ### New interface for reporters -The reporter interface has changed. The callbacks are different and more consistent. The objects passed in should only provide what is needed to report results. This enforces an interface to result data so custom reporters will be less coupled to Jasmine implementation. The full suite execution time is also reported. +The reporter interface has been **replaced**. The callbacks are different and more consistent. The objects passed in should only provide what is needed to report results. This enforces an interface to result data so custom reporters will be less coupled to the Jasmine implementation. The Jasmine reporter API now includes a slot for a `timer` object. ### Better Equality testing -We have tossed the previous equality code and are now using new code for testing equality. We started with [Underscore.js][underscore]'s `isEqual`, refactored a bit and added some additional tests. +We removed the previous equality code and are now using new code for testing equality. We started with [Underscore.js][underscore]'s `isEqual`, refactored a bit and added some additional tests. -### Easier custom matchers +### Replaced custom matchers for ease of use -Custom matchers have always been possible, but this was barely documented and clunky to test. We've changed how matchers are added and tested. Jasmine adds its own matchers by the same mechanism that as custom matchers use. Dogfooding FTW. +The interface for adding custom matchers has been **replaced**. It has always been possible to add custom matchers, but the API was barely documented and difficult to test. We've changed how matchers are added and tested. Jasmine adds its own matchers by the same mechanism that custom matchers use. Dogfooding FTW. ### Change to `toThrow` matcher @@ -43,9 +43,9 @@ We've changed the behavior of the `toThrow` matcher, moving some functionality t * Massive refactoring and better testing * Environment setup now in `boot.js` -* Development & Build moved to Grunt -* Change in how Jasmine is loaded -* Change in how Jasmine is tested +* Development and Build moved to Grunt +* Changes to how Jasmine is loaded +* Changes to how Jasmine is tested * Better node.js support * Better Continuous Integration Environment at Travis * Support matrix updated @@ -53,39 +53,39 @@ We've changed the behavior of the `toThrow` matcher, moving some functionality t ## Massive refactoring and better testing -This is the biggest set of changes. We've touched nearly every file and every object. We've slammed objects back together and pulled out new extractions. We've made the code more consistently styled. We've improved the tests nearly everywhere. +This is the biggest set of changes. We've touched nearly every file and every object. We've merged objects together and factored out code. We styled the code more consistently. We've improved nearly every test. -In general, Jasmine is made of smaller, more-loosely-coupled objects, unit-tested with explicit dependencies injected. This made tests easier to write, read, and maintain. We know this has made Jasmine development easier for the core team. We expect (and hope) this makes it easier for the community to extend Jasmine and provide pull requests that make more sense the first time out. +In general, Jasmine is made of smaller, more-loosely-coupled objects, unit-tested with explicit dependencies injected. This made tests easier to read, write, and maintain. We know this has made Jasmine development easier for the core team. We expect (and hope) this makes it easier for the community to extend Jasmine and provide pull requests that make more sense the first time out. ## Environment setup now in `boot.js` Instantiation and setup of the Jasmine environment, including building reporters, exposing the "global" functions, and executing tests has moved into its own file: `boot.js`. This should make it easier to add custom reporters, configure some objects, or just in general change how you use Jasmine from the outside. -For example, during development, Jasmine uses it's own `devboot.js` to load itself twice - once from `jasmine.js` and once from the source directories. +For example, during development, Jasmine uses its own `devboot.js` to load itself twice - once from `jasmine.js` and once from the source directories. -## Development & Build moved to Grunt +## Development and Build moved to Grunt -We've moved away from Ruby and embraced Node.js and [Grunt.js][grunt] for the various command line tasks during development. Yes, it's a just a different set of dependencies. But it's less code for the team to maintain - it turns out that JavaScript tools are pretty good at building JavaScript projects. This will make it easier for the community to make sure contributions work in browser and in Node.js before submitting Pull Requests. There is more detail in the [Contributor's Guide][contrib]. +We've moved away from Ruby and embraced [Node.js][node] and [Grunt.js][grunt] for the various command line tasks during development. Yes, it's a just a different set of dependencies. But it's less code for the team to maintain - it turns out that JavaScript tools are pretty good at building JavaScript projects. This will make it easier for the community to make sure contributions work in browsers and in Node.js before submitting Pull Requests. There is more detail in the [Contributor's Guide][contrib]. -## Change in how Jasmine is loaded +## Changes to how Jasmine is loaded -We did not want to add new run-time dependencies, yet we needed to be cleaner when loading Jasmine. So we wrote a custom "require" scheme that works in Node.js and in browsers. This only affects pull requests that add files - please be careful in these cases. Again, the [Contributor's Guide][contrib] should help. +We did not want to add new run-time dependencies, yet we needed to be cleaner when loading Jasmine. So we wrote a custom "require" scheme that works in Node.js and in browsers. This only affects pull requests which add files - please be careful in these cases. Again, the [Contributor's Guide][contrib] should help. -## Change in how Jasmine is tested with Jasmine +## Changes to how Jasmine is tested with Jasmine Writing a custom require system helped enforce self-testing - the built `jasmine.js` testing Jasmine from the source directories. Overall this has improved the stability of the code. When you look at Jasmine's tests, you'll see both `jasmine` and `j$` used. The former, `jasmine`, will always be used to test the code from source, which is loaded into the reference `j$`. Please adhere to this pattern when writing tests for contributions. ## Better node.js support -Node.js is now officially a first-class citizen. For a long time we've made sure tests were green in Node before releasing. But it is now officially part of Jasmine's CI build at [Travis][travis]. For the curious, the [`node_suite.js`][node_suite], is essentially a `boot.js` for Node. An official npm is coming. +`Node.js` is now officially a first-class citizen. For a long time we've made sure tests were green in Node before releasing. But it is now officially part of Jasmine's CI build at [Travis][travis]. For the curious, the [`node_suite.js`][node_suite], is essentially a `boot.js` for Node. An official `npm` is coming. ## Better Continuous Integration Environment at Travis -The [CI build at Travis][travis_jasmine] now runs the core specs in a build matrix across browsers. It's far from complete on the operating system matrix, but you will see that Jasmine runs against: Firefox, Chrome, Safari 5, Safari 6, Phantom.js, Node.js, and IE versions 8, 9, and 10. Big thanks to [SauceLabs][sauce] for their support of open source projects. We will happily take pull requests for additional OS/Browser combos within the matrix. +The [CI build at Travis][travis_jasmine] now runs the core specs in a build matrix across browsers. It's far from complete on the operating system matrix, but you will see that Jasmine runs against: Firefox, Chrome, Safari 5, Safari 6, [Phantom.js][phantom], [Node.js][node], and IE versions 8, 9, and 10. Big thanks to [SauceLabs][sauce] for their support of open source projects. We will happily take pull requests for additional OS/Browser combos within the matrix. ## Support Matrix Updated -We're dropping support for IE < 8. Jasmine 1.x remains for projects supporting earlier versions of browsers. +We're dropping support for IE < 8. [Jasmine 1.x][jasmine_downloads] remains for projects that need to support older browsers. ## Removed JsDoc Pages @@ -93,7 +93,7 @@ Comments in code are lies waiting to happen. Jasmine's JsDoc comments were no ex Last year saw the posting of the [`introduction.js`][intro] page to document the real, practical interface for projects to use. This page has received a lot of positive feedback so expect more pages like this one. -## Pull Requests & Issues +## Pull Requests and Issues The following Pull Requests were merged: @@ -110,7 +110,7 @@ The following Pull Requests were merged: There were several other pull requests that either had already been fixed, or were good starting points for the various changes above. Thank you for all of the hard work to keep Jasmine awesome. -## Other Bugs & Features +## Other Bugs and Features There were a few small changes and fixes that didn't fit into any of the above categories: @@ -130,7 +130,10 @@ _Release Notes generated with [Anchorman](http://github.com/infews/anchorman)_ [mocha]: http://visionmedia.github.io/mocha/ [underscore]: http://underscorejs.org/ [grunt]: http://gruntjs.com -[contrib]: https://github.com/pivotal/jasmine/blob/master/Contribute.markdown +[node]: http://nodejs.org +[phantom]: http://phantomjs.org +[jasmine_downloads]: https://github.com/pivotal/jasmine/downloads +[contrib]: https://github.com/pivotal/jasmine/blob/master/CONTRIBUTING.md [travis]: http://travis-ci.org [travis_jasmine]: http://travis-ci.org/jasmine [sauce]: http://saucelabs.com diff --git a/release_notes/20rc3.md b/release_notes/20rc3.md index ea6ffbd5..489f8b26 100644 --- a/release_notes/20rc3.md +++ b/release_notes/20rc3.md @@ -6,34 +6,34 @@ These notes are for RC3 of Jasmine Core 2.0. ## Breaking Changes -The [`introduction.js`][intro] page covers the current syntax, highlighting the changes. Here are known breaking interface changes that are not backwards compatible with 1.x. +The [`introduction.js`][intro] page covers the current syntax, highlighting the changes. Here are the known interface changes that are not backwards compatible with 1.x. * New syntax for asynchronous specs * New syntax for spies * New interface for reporters * Better Equality testing -* Easier custom matchers +* Replaced custom matchers for ease of use * Change to `toThrow` matcher ### New syntax for asynchronous specs -Similar to [Mocha][mocha], Jasmine befores, specs, and afters can take an optional "done" callback in order to force asynchronous tests. The next function, whether it's a before, spec or after, will wait until this function is called or if a timeout is reached. +Similar to [Mocha][mocha], Jasmine `before`s, `spec`s, and `after`s can take an optional `done` callback in order to force asynchronous tests. The next function, whether it's a `before`, `spec` or `after`, will wait until this function is called or until a timeout is reached. ### New syntax for spies -Spies have a slightly modified syntax. The ideas came from a desire to preserve any of the properties on a spied-upon function and some better testing patterns. +Spies have a slightly modified syntax. The idea came from a desire to preserve any of the properties on a spied-upon function and some better testing patterns. ### New interface for reporters -The reporter interface has changed. The callbacks are different and more consistent. The objects passed in should only provide what is needed to report results. This enforces an interface to result data so custom reporters will be less coupled to Jasmine implementation. The full suite execution time is also reported. +The reporter interface has been **replaced**. The callbacks are different and more consistent. The objects passed in should only provide what is needed to report results. This enforces an interface to result data so custom reporters will be less coupled to the Jasmine implementation. The Jasmine reporter API now includes a slot for a `timer` object. ### Better Equality testing -We have tossed the previous equality code and are now using new code for testing equality. We started with [Underscore.js][underscore]'s `isEqual`, refactored a bit and added some additional tests. +We removed the previous equality code and are now using new code for testing equality. We started with [Underscore.js][underscore]'s `isEqual`, refactored a bit and added some additional tests. -### Easier custom matchers +### Replaced custom matchers for ease of use -Custom matchers have always been possible, but this was barely documented and clunky to test. We've changed how matchers are added and tested. Jasmine adds its own matchers by the same mechanism that as custom matchers use. Dogfooding FTW. +The interface for adding custom matchers has been **replaced**. It has always been possible to add custom matchers, but the API was barely documented and difficult to test. We've changed how matchers are added and tested. Jasmine adds its own matchers by the same mechanism that custom matchers use. Dogfooding FTW. ### Change to `toThrow` matcher @@ -43,9 +43,9 @@ We've changed the behavior of the `toThrow` matcher, moving some functionality t * Massive refactoring and better testing * Environment setup now in `boot.js` -* Development & Build moved to Grunt -* Change in how Jasmine is loaded -* Change in how Jasmine is tested +* Development and Build moved to Grunt +* Changes to how Jasmine is loaded +* Changes to how Jasmine is tested * Better node.js support * Better Continuous Integration Environment at Travis * Support matrix updated @@ -53,39 +53,39 @@ We've changed the behavior of the `toThrow` matcher, moving some functionality t ## Massive refactoring and better testing -This is the biggest set of changes. We've touched nearly every file and every object. We've slammed objects back together and pulled out new extractions. We've made the code more consistently styled. We've improved the tests nearly everywhere. +This is the biggest set of changes. We've touched nearly every file and every object. We've merged objects together and factored out code. We styled the code more consistently. We've improved nearly every test. -In general, Jasmine is made of smaller, more-loosely-coupled objects, unit-tested with explicit dependencies injected. This made tests easier to write, read, and maintain. We know this has made Jasmine development easier for the core team. We expect (and hope) this makes it easier for the community to extend Jasmine and provide pull requests that make more sense the first time out. +In general, Jasmine is made of smaller, more-loosely-coupled objects, unit-tested with explicit dependencies injected. This made tests easier to read, write, and maintain. We know this has made Jasmine development easier for the core team. We expect (and hope) this makes it easier for the community to extend Jasmine and provide pull requests that make more sense the first time out. ## Environment setup now in `boot.js` Instantiation and setup of the Jasmine environment, including building reporters, exposing the "global" functions, and executing tests has moved into its own file: `boot.js`. This should make it easier to add custom reporters, configure some objects, or just in general change how you use Jasmine from the outside. -For example, during development, Jasmine uses it's own `devboot.js` to load itself twice - once from `jasmine.js` and once from the source directories. +For example, during development, Jasmine uses its own `devboot.js` to load itself twice - once from `jasmine.js` and once from the source directories. -## Development & Build moved to Grunt +## Development and Build moved to Grunt -We've moved away from Ruby and embraced Node.js and [Grunt.js][grunt] for the various command line tasks during development. Yes, it's a just a different set of dependencies. But it's less code for the team to maintain - it turns out that JavaScript tools are pretty good at building JavaScript projects. This will make it easier for the community to make sure contributions work in browser and in Node.js before submitting Pull Requests. There is more detail in the [Contributor's Guide][contrib]. +We've moved away from Ruby and embraced [Node.js][node] and [Grunt.js][grunt] for the various command line tasks during development. Yes, it's a just a different set of dependencies. But it's less code for the team to maintain - it turns out that JavaScript tools are pretty good at building JavaScript projects. This will make it easier for the community to make sure contributions work in browsers and in Node.js before submitting Pull Requests. There is more detail in the [Contributor's Guide][contrib]. -## Change in how Jasmine is loaded +## Changes to how Jasmine is loaded -We did not want to add new run-time dependencies, yet we needed to be cleaner when loading Jasmine. So we wrote a custom "require" scheme that works in Node.js and in browsers. This only affects pull requests that add files - please be careful in these cases. Again, the [Contributor's Guide][contrib] should help. +We did not want to add new run-time dependencies, yet we needed to be cleaner when loading Jasmine. So we wrote a custom "require" scheme that works in Node.js and in browsers. This only affects pull requests which add files - please be careful in these cases. Again, the [Contributor's Guide][contrib] should help. -## Change in how Jasmine is tested with Jasmine +## Changes to how Jasmine is tested with Jasmine Writing a custom require system helped enforce self-testing - the built `jasmine.js` testing Jasmine from the source directories. Overall this has improved the stability of the code. When you look at Jasmine's tests, you'll see both `jasmine` and `j$` used. The former, `jasmine`, will always be used to test the code from source, which is loaded into the reference `j$`. Please adhere to this pattern when writing tests for contributions. ## Better node.js support -Node.js is now officially a first-class citizen. For a long time we've made sure tests were green in Node before releasing. But it is now officially part of Jasmine's CI build at [Travis][travis]. For the curious, the [`node_suite.js`][node_suite], is essentially a `boot.js` for Node. An official npm is coming. +`Node.js` is now officially a first-class citizen. For a long time we've made sure tests were green in Node before releasing. But it is now officially part of Jasmine's CI build at [Travis][travis]. For the curious, the [`node_suite.js`][node_suite], is essentially a `boot.js` for Node. An official `npm` is coming. ## Better Continuous Integration Environment at Travis -The [CI build at Travis][travis_jasmine] now runs the core specs in a build matrix across browsers. It's far from complete on the operating system matrix, but you will see that Jasmine runs against: Firefox, Chrome, Safari 5, Safari 6, Phantom.js, Node.js, and IE versions 8, 9, and 10. Big thanks to [SauceLabs][sauce] for their support of open source projects. We will happily take pull requests for additional OS/Browser combos within the matrix. +The [CI build at Travis][travis_jasmine] now runs the core specs in a build matrix across browsers. It's far from complete on the operating system matrix, but you will see that Jasmine runs against: Firefox, Chrome, Safari 5, Safari 6, [Phantom.js][phantom], [Node.js][node], and IE versions 8, 9, and 10. Big thanks to [SauceLabs][sauce] for their support of open source projects. We will happily take pull requests for additional OS/Browser combos within the matrix. ## Support Matrix Updated -We're dropping support for IE < 8. Jasmine 1.x remains for projects supporting earlier versions of browsers. +We're dropping support for IE < 8. [Jasmine 1.x][jasmine_downloads] remains for projects that need to support older browsers. ## Removed JsDoc Pages @@ -93,7 +93,7 @@ Comments in code are lies waiting to happen. Jasmine's JsDoc comments were no ex Last year saw the posting of the [`introduction.js`][intro] page to document the real, practical interface for projects to use. This page has received a lot of positive feedback so expect more pages like this one. -## Pull Requests & Issues +## Pull Requests and Issues The following Pull Requests were merged: @@ -114,7 +114,7 @@ The following Pull Requests were merged: There were several other pull requests that either had already been fixed, or were good starting points for the various changes above. Thank you for all of the hard work to keep Jasmine awesome. -## Other Bugs & Features +## Other Bugs and Features There were a few small changes and fixes that didn't fit into any of the above categories: @@ -139,6 +139,9 @@ There were a few small changes and fixes that didn't fit into any of the above c [mocha]: http://visionmedia.github.io/mocha/ [underscore]: http://underscorejs.org/ [grunt]: http://gruntjs.com +[node]: http://nodejs.org +[phantom]: http://phantomjs.org +[jasmine_downloads]: https://github.com/pivotal/jasmine/downloads [contrib]: https://github.com/pivotal/jasmine/blob/master/CONTRIBUTING.md [travis]: http://travis-ci.org [travis_jasmine]: http://travis-ci.org/jasmine diff --git a/release_notes/20rc5.md b/release_notes/20rc5.md index 25b3484d..f092af86 100644 --- a/release_notes/20rc5.md +++ b/release_notes/20rc5.md @@ -6,44 +6,44 @@ These notes are for RC5 of Jasmine Core 2.0. ## Breaking Changes -The [`introduction.js`][intro] page covers the current syntax, highlighting the changes. Here are known breaking interface changes that are not backwards compatible with 1.x. +The [`introduction.js`][intro] page covers the current syntax, highlighting the changes. Here are the known interface changes that are not backwards compatible with 1.x. * New syntax for asynchronous specs * New syntax for spies * New interface for reporters * Better Equality testing -* Easier custom matchers +* Replaced custom matchers for ease of use * Change to `toThrow` matcher -* Clock does not uninstall itself at the end of a spec +* Clock now remains installed when a spec finishes * More Jasmine internal variables/functions have been moved into closures ### New syntax for asynchronous specs -Similar to [Mocha][mocha], Jasmine befores, specs, and afters can take an optional "done" callback in order to force asynchronous tests. The next function, whether it's a before, spec or after, will wait until this function is called or if a timeout is reached. +Similar to [Mocha][mocha], Jasmine `before`s, `spec`s, and `after`s can take an optional `done` callback in order to force asynchronous tests. The next function, whether it's a `before`, `spec` or `after`, will wait until this function is called or until a timeout is reached. ### New syntax for spies -Spies have a slightly modified syntax. The ideas came from a desire to preserve any of the properties on a spied-upon function and some better testing patterns. +Spies have a slightly modified syntax. The idea came from a desire to preserve any of the properties on a spied-upon function and some better testing patterns. ### New interface for reporters -The reporter interface has changed. The callbacks are different and more consistent. The objects passed in should only provide what is needed to report results. This enforces an interface to result data so custom reporters will be less coupled to Jasmine implementation. The full suite execution time is also reported. +The reporter interface has been **replaced**. The callbacks are different and more consistent. The objects passed in should only provide what is needed to report results. This enforces an interface to result data so custom reporters will be less coupled to the Jasmine implementation. The Jasmine reporter API now includes a slot for a `timer` object. ### Better Equality testing -We have tossed the previous equality code and are now using new code for testing equality. We started with [Underscore.js][underscore]'s `isEqual`, refactored a bit and added some additional tests. +We removed the previous equality code and are now using new code for testing equality. We started with [Underscore.js][underscore]'s `isEqual`, refactored a bit and added some additional tests. -### Easier custom matchers +### Replaced custom matchers for ease of use -Custom matchers have always been possible, but this was barely documented and clunky to test. We've changed how matchers are added and tested. Jasmine adds its own matchers by the same mechanism that as custom matchers use. Dogfooding FTW. +The interface for adding custom matchers has been **replaced**. It has always been possible to add custom matchers, but the API was barely documented and difficult to test. We've changed how matchers are added and tested. Jasmine adds its own matchers by the same mechanism that custom matchers use. Dogfooding FTW. ### Change to `toThrow` matcher We've changed the behavior of the `toThrow` matcher, moving some functionality to the `toThrowError` matcher. This should allow more of the requested use cases. -### Clock does not uninstall itself at the end of a spec +### Clock now remains installed when a spec finishes -After installing the Jasmine Clock, it will stay installed until uninstall is called -- clearing up any ambiguity for when those timing functions will go back to being the actual ones. +After installing the Jasmine Clock, it will stay installed until `uninstall` is called -- clearing up any ambiguity for when those timing functions will revert to using the global clock object. ## More Jasmine internal variables/functions have been moved into closures @@ -53,9 +53,9 @@ Certain variables/functions like a function to get the next spec id have been mo * Massive refactoring and better testing * Environment setup now in `boot.js` -* Development & Build moved to Grunt -* Change in how Jasmine is loaded -* Change in how Jasmine is tested +* Development and Build moved to Grunt +* Changes to how Jasmine is loaded +* Changes to how Jasmine is tested * Better node.js support * Better Continuous Integration Environment at Travis * Support matrix updated @@ -64,39 +64,39 @@ Certain variables/functions like a function to get the next spec id have been mo ## Massive refactoring and better testing -This is the biggest set of changes. We've touched nearly every file and every object. We've slammed objects back together and pulled out new extractions. We've made the code more consistently styled. We've improved the tests nearly everywhere. +This is the biggest set of changes. We've touched nearly every file and every object. We've merged objects together and factored out code. We styled the code more consistently. We've improved nearly every test. -In general, Jasmine is made of smaller, more-loosely-coupled objects, unit-tested with explicit dependencies injected. This made tests easier to write, read, and maintain. We know this has made Jasmine development easier for the core team. We expect (and hope) this makes it easier for the community to extend Jasmine and provide pull requests that make more sense the first time out. +In general, Jasmine is made of smaller, more-loosely-coupled objects, unit-tested with explicit dependencies injected. This made tests easier to read, write, and maintain. We know this has made Jasmine development easier for the core team. We expect (and hope) this makes it easier for the community to extend Jasmine and provide pull requests that make more sense the first time out. ## Environment setup now in `boot.js` Instantiation and setup of the Jasmine environment, including building reporters, exposing the "global" functions, and executing tests has moved into its own file: `boot.js`. This should make it easier to add custom reporters, configure some objects, or just in general change how you use Jasmine from the outside. -For example, during development, Jasmine uses it's own `devboot.js` to load itself twice - once from `jasmine.js` and once from the source directories. +For example, during development, Jasmine uses its own `devboot.js` to load itself twice - once from `jasmine.js` and once from the source directories. -## Development & Build moved to Grunt +## Development and Build moved to Grunt -We've moved away from Ruby and embraced Node.js and [Grunt.js][grunt] for the various command line tasks during development. Yes, it's a just a different set of dependencies. But it's less code for the team to maintain - it turns out that JavaScript tools are pretty good at building JavaScript projects. This will make it easier for the community to make sure contributions work in browser and in Node.js before submitting Pull Requests. There is more detail in the [Contributor's Guide][contrib]. +We've moved away from Ruby and embraced [Node.js][node] and [Grunt.js][grunt] for the various command line tasks during development. Yes, it's a just a different set of dependencies. But it's less code for the team to maintain - it turns out that JavaScript tools are pretty good at building JavaScript projects. This will make it easier for the community to make sure contributions work in browsers and in Node.js before submitting Pull Requests. There is more detail in the [Contributor's Guide][contrib]. -## Change in how Jasmine is loaded +## Changes to how Jasmine is loaded -We did not want to add new run-time dependencies, yet we needed to be cleaner when loading Jasmine. So we wrote a custom "require" scheme that works in Node.js and in browsers. This only affects pull requests that add files - please be careful in these cases. Again, the [Contributor's Guide][contrib] should help. +We did not want to add new run-time dependencies, yet we needed to be cleaner when loading Jasmine. So we wrote a custom "require" scheme that works in Node.js and in browsers. This only affects pull requests which add files - please be careful in these cases. Again, the [Contributor's Guide][contrib] should help. -## Change in how Jasmine is tested with Jasmine +## Changes to how Jasmine is tested with Jasmine Writing a custom require system helped enforce self-testing - the built `jasmine.js` testing Jasmine from the source directories. Overall this has improved the stability of the code. When you look at Jasmine's tests, you'll see both `jasmine` and `j$` used. The former, `jasmine`, will always be used to test the code from source, which is loaded into the reference `j$`. Please adhere to this pattern when writing tests for contributions. ## Better node.js support -Node.js is now officially a first-class citizen. For a long time we've made sure tests were green in Node before releasing. But it is now officially part of Jasmine's CI build at [Travis][travis]. For the curious, the [`node_suite.js`][node_suite], is essentially a `boot.js` for Node. An official npm is coming. +`Node.js` is now officially a first-class citizen. For a long time we've made sure tests were green in Node before releasing. But it is now officially part of Jasmine's CI build at [Travis][travis]. For the curious, the [`node_suite.js`][node_suite], is essentially a `boot.js` for Node. An official `npm` is coming. ## Better Continuous Integration Environment at Travis -The [CI build at Travis][travis_jasmine] now runs the core specs in a build matrix across browsers. It's far from complete on the operating system matrix, but you will see that Jasmine runs against: Firefox, Chrome, Safari 5, Safari 6, Phantom.js, Node.js, and IE versions 8, 9, and 10. Big thanks to [SauceLabs][sauce] for their support of open source projects. We will happily take pull requests for additional OS/Browser combos within the matrix. +The [CI build at Travis][travis_jasmine] now runs the core specs in a build matrix across browsers. It's far from complete on the operating system matrix, but you will see that Jasmine runs against: Firefox, Chrome, Safari 5, Safari 6, [Phantom.js][phantom], [Node.js][node], and IE versions 8, 9, and 10. Big thanks to [SauceLabs][sauce] for their support of open source projects. We will happily take pull requests for additional OS/Browser combos within the matrix. ## Support Matrix Updated -We're dropping support for IE < 8. Jasmine 1.x remains for projects supporting earlier versions of browsers. +We're dropping support for IE < 8. [Jasmine 1.x][jasmine_downloads] remains for projects that need to support older browsers. ## Removed JsDoc Pages @@ -108,7 +108,7 @@ Last year saw the posting of the [`introduction.js`][intro] page to document the We are running Code Climate for Jasmine. We have some work to do here but it's helping us easily find code hotspots. -## Pull Requests & Issues +## Pull Requests and Issues The following Pull Requests were merged: @@ -138,7 +138,7 @@ The following Pull Requests were merged: There were several other pull requests that either had already been fixed, or were good starting points for the various changes above. Thank you for all of the hard work to keep Jasmine awesome. -## Other Bugs & Features +## Other Bugs and Features There were a few small changes and fixes that didn't fit into any of the above categories: @@ -163,6 +163,9 @@ There were a few small changes and fixes that didn't fit into any of the above c [mocha]: http://visionmedia.github.io/mocha/ [underscore]: http://underscorejs.org/ [grunt]: http://gruntjs.com +[node]: http://nodejs.org +[phantom]: http://phantomjs.org +[jasmine_downloads]: https://github.com/pivotal/jasmine/downloads [contrib]: https://github.com/pivotal/jasmine/blob/master/CONTRIBUTING.md [travis]: http://travis-ci.org [travis_jasmine]: http://travis-ci.org/jasmine