From cc42bdabf4a795da40e9e39036a901f20b550ca0 Mon Sep 17 00:00:00 2001 From: Jan Steemann Date: Tue, 17 Feb 2015 09:05:00 +0100 Subject: [PATCH] typos etc. --- CHANGELOG | 86 ++++++++++++++++++++++++++++++------------------------- 1 file changed, 47 insertions(+), 39 deletions(-) diff --git a/CHANGELOG b/CHANGELOG index 65191c23a5..a8c5d1c83b 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -1,56 +1,64 @@ v2.5.0-alpha2 (2015-02-16) ------------------- -* Simplify the entry to foxx +* Simplify usage of Foxx - Thanks to our user feedback we learned that foxx is a powerful, yet rather complicated concept. - With this release we tried to make it less complicated while keeping all it's strength. + Thanks to our user feedback we learned that Foxx is a powerful, yet rather complicated concept. + With this release we tried to make it less complicated while keeping all its strength. That includes a rewrite of the documentation as well as some code changes as listed below: -* Moved Foxx applications to a different folder. - - The naming convention now is: /_db///APP - Before it was: /databases//: - This caused some trouble as apps where cached based on name and version and updates did not apply. - Hence the path on filesystem and the url to access had no relation to one another. - Now the path on filesystem is identical to the url (except for slashes and the appended APP) + * Moved Foxx applications to a different folder. + + The naming convention now is: /_db///APP + Before it was: /databases//: + This caused some trouble as apps where cached based on name and version and updates did not apply. + Hence the path on filesystem and the app's access URL had no relation to one another. + Now the path on filesystem is identical to the URL (except for slashes and the appended APP) -* Rewrite of Foxx routing + * Rewrite of Foxx routing - The routing of Foxx has been exposed to major internal changes we adjusted because of user feedback. - This allows us to set the development mode per mountpoint without having to change pathes and hold - apps at seperate locations. + The routing of Foxx has been exposed to major internal changes we adjusted because of user feedback. + This allows us to set the development mode per mountpoint without having to change pathes and hold + apps at seperate locations. -* Foxx Development mode + * Foxx Development mode - The development mode used until 2.4 is gone. It has been replaced by a much more mature version. - This includes the deprecation of the javascript.dev-app-path parameter which is useless since 2.5 - Instead all apps are located at the same location production as well as development. - But you can set specfic apps into development mode changeing their behaviour compared to - production apps: They are rerouted from disc on any request, they ship more debug output on routes. + The development mode used until 2.4 is gone. It has been replaced by a much more mature version. + This includes the deprecation of the javascript.dev-app-path parameter, which is useless since 2.5. + Instead of having two separate app directories for production and development, apps now reside in + one place, which is used for production as well as for development. + Apps can still be put into development mode, changing their behavior compared to production mode. + Development mode apps are still reread from disk at every request, and still they ship more debug + output. -* Foxx install process + * Foxx install process - Installing of foxxes has been a two step process: import them in arangodb and mount them on a - specific mountpoint. These operations have been joined together. You install an app on one - mountpoint, thats it. No fetch, mount, unmound, purge anymore. - * Install: get your foxx up and running. - * Uninstall: shut it down and erase it from disc. + Installing Foxx apps has been a two step process: import them into ArangoDB and mount them at a + specific mountpoint. These operations have been joined together. You can install an app at one + mountpoint, that's it. No fetch, mount, unmount, purge cycle anymore. The commands have been + simplified to just: -* Foxx error output + * install: get your Foxx app up and running + * uninstall: shut it down and erase it from disk - Until 2.4 the errors produced by foxx where not optimal. If any they created only in internal - stack trace and always returned with 'unable to parse manifest'. - In 2.5 we made major improvements there, including a much more finegrained error output that - helps you debug your foxxes. The error is now much closer to it's source and should help you - track it down. - Also we added the default handlers for unhandled errors in your foxxes. - * You will get a nice internal error page whenever your foxx cannot be installed. - * You will get a propper error message when having an unhandled error in your route. - In production mode the messages above will NOT contain any information about your foxx internals - and are save to be exposed to third party. - In development mode the messages above will contain the stacktrace if available making it easier for - your in-house devs to track down the errors in their application. + * Foxx error output + + Until 2.4 the errors produced by Foxx were not optimal. Often, the error message was just + `unable to parse manifest` and contained only an internal stack trace. + In 2.5 we made major improvements there, including a much more finegrained error output that + helps you debug your Foxx apps. The error message printed is now much closer to its source and + should help you track it down. + + Also we added the default handlers for unhandled errors in Foxx apps: + + * You will get a nice internal error page whenever your Foxx app is called but was not installed + due to any error + * You will get a proper error message when having an uncaught error appears in any app route + + In production mode the messages above will NOT contain any information about your Foxx internals + and are safe to be exposed to third party users. + In development mode the messages above will contain the stacktrace (if available), making it easier for + your in-house devs to track down errors in the application. * added optimizer rule `propagate-constant-attributes`