Prepare 0.5.0 release

Makefile

@@ -27,9 +27,9 @@ docs: docs_api docs_site
 .PHONY: docs_api
 docs_api:
 	crystal docs --output=docs/static/api/dev
-	cp -R docs/static/api/dev/ docs/static/api/0.2
 	cp -R docs/static/api/dev/ docs/static/api/0.3
 	cp -R docs/static/api/dev/ docs/static/api/0.4
+	cp -R docs/static/api/dev/ docs/static/api/0.5
 
 .PHONY: docs_site
 docs_site:

docs/docs/caching/how-to/create-custom-cache-stores.md

@@ -138,7 +138,7 @@ end
 
 ## Enabling the use of custom cache stores
 
-Custom cache store can be used by assigning an instance of the corresponding class to the [`cache_store`](../../development/reference/settings.md#cache-store1) setting.
+Custom cache store can be used by assigning an instance of the corresponding class to the [`cache_store`](../../development/reference/settings.md#cache_store) setting.
 
 For example:
 

docs/docs/development/applications.md

@@ -16,7 +16,7 @@ Another benefit of applications is that they can be packaged and reused across m
 
 ## Using applications
 
-The use of applications must be manually enabled within projects: this is done through the use of the [`installed_apps`](./reference/settings.md#installedapps) setting.
+The use of applications must be manually enabled within projects: this is done through the use of the [`installed_apps`](./reference/settings.md#installed_apps) setting.
 
 This setting corresponds to an array of installed app classes. Indeed, each Marten application must define a subclass of [`Marten::App`](pathname:///api/dev/Marten/App.html) to specify a few things such as the application label (see [Creating applications](#creating-applications) for more information about this). When those subclasses are specified in the `installed_apps` setting, the applications' models, migrations, assets, and templates will be made available to the considered project.
 
@@ -40,7 +40,7 @@ Adding an application class inside this array will have the following impact on
 
 ### The main application
 
-The "main" application is a default application that is always implicitly used by Marten projects (which means that it does not appear in the [`installed_apps`](./reference/settings.md#installedapps) setting). This application is associated with the standard `src` folder: this means that models, migrations, assets, or templates defined in this folder will be associated with the main application by default. For example, models defined under a `src/models` folder would be associated with the main application.
+The "main" application is a default application that is always implicitly used by Marten projects (which means that it does not appear in the [`installed_apps`](./reference/settings.md#installed_apps) setting). This application is associated with the standard `src` folder: this means that models, migrations, assets, or templates defined in this folder will be associated with the main application by default. For example, models defined under a `src/models` folder would be associated with the main application.
 
 :::info
 The main application is associated with the `main` label. This means that models of the main application that do not define an explicit table name will have table names starting with `main_`.
@@ -52,7 +52,7 @@ In the end, the main application provides a convenient way for starting projects
 
 ### Order of installed applications
 
-You should note that the order in which installed applications are defined in the [`installed_apps`](./reference/settings.md#installedapps) setting can actually matter.
+You should note that the order in which installed applications are defined in the [`installed_apps`](./reference/settings.md#installed_apps) setting can actually matter.
 
 For example, a "foo" app might define a `test.html` template, and a similar template with the exact same name might be defined by a "bar" app. If the "foo" app appears before the "bar" app in the array of installed apps, then requesting and rendering the `test.html` template will actually involve the "foo" app's template only. This is because template loaders associated with app directories iterate over applications in the order in which they are defined in the installed apps array.
 

docs/docs/models-and-databases/how-to/create-custom-model-fields.md

@@ -137,7 +137,7 @@ def from_db_result_set(result_set : ::DB::ResultSet) : ::UUID?
 end
 ```
 
-The `#from_db_result_set` method is supposed to return the read value into the right "representation", that is the final object representing the field value that users will interact with when manipulating model records (for example a `UUID` object created from a string). As such, you will usually want to call [`#from_db`](#fromdb) once you get the value from the database result set in order to return the final value.
+The `#from_db_result_set` method is supposed to return the read value into the right "representation", that is the final object representing the field value that users will interact with when manipulating model records (for example a `UUID` object created from a string). As such, you will usually want to call [`#from_db`](#from_db) once you get the value from the database result set in order to return the final value.
 
 #### `to_column`
 
@@ -163,7 +163,7 @@ If for some reason your custom field does not contribute any columns to the data
 
 #### `to_db`
 
-The `#to_db` method converts a field value from the "Crystal" representation to the database representation. As such, this method performs the reverse operation of the [`#from_db`](#fromdb) method.
+The `#to_db` method converts a field value from the "Crystal" representation to the database representation. As such, this method performs the reverse operation of the [`#from_db`](#from_db) method.
 
 For example, this method could return the string representation of a `UUID` object:
 

docs/docs/models-and-databases/introduction.md

@@ -405,7 +405,7 @@ Please head over to the [Model validations](./validations.md) guide in order to
 
 Model classes can inherit from each other. This allows you to easily reuse the field definitions and table attributes of a parent model within a child model.
 
-Presently, the Marten web framework allows [abstract model inheritance](#inheriting-from-abstract-models) (which is useful in order to reuse shared model fields and patterns over multiple child models without having a database table created for the parent model) and [multi-table inheritance](#multi-table-inheritance).
+Presently, the Marten web framework allows [abstract model inheritance](#abstract-model-inheritance) (which is useful in order to reuse shared model fields and patterns over multiple child models without having a database table created for the parent model) and [multi-table inheritance](#multi-table-inheritance).
 
 ### Abstract model inheritance
 

docs/docs/models-and-databases/reference/query-set.md

@@ -123,7 +123,7 @@ query_set_1 = Post.all.distinct
 query_set_2 = Post.all.distinct(:title)
 ```
 
-It should be noted that it is also possible to follow associations of direct related models too by using the [double underscores notation](../queries.md#joins-and-filtering-relations) (`__`). For example the following query will select distinct records based on a joined "author" attribute:
+It should be noted that it is also possible to follow associations of direct related models too by using the [double underscores notation](../queries.md#filtering-relations) (`__`). For example the following query will select distinct records based on a joined "author" attribute:
 
 ```
 query_set = Post.all.distinct(:author__name)
@@ -171,7 +171,7 @@ query_set.filter { (q(name: "Foo") | q(name: "Bar")) & q(is_published: True) }
 
 ### `join`
 
-Returns a queryset whose specified `relations` are "followed" and joined to each result (see [Queries](../queries.md#joins-and-filtering-relations) for an introduction about this capability).
+Returns a queryset whose specified `relations` are "followed" and joined to each result (see [Queries](../queries.md#filtering-relations) for an introduction about this capability).
 
 When using `#join`, the specified relationships will be followed and each record returned by the queryset will have the corresponding related objects already selected and populated. Using `#join` can result in performance improvements since it can help reduce the number of SQL queries, as illustrated by the following example:
 

docs/docs/models-and-databases/transactions.md

@@ -43,7 +43,7 @@ When transaction blocks are nested, this results in all the database statements
 
 Basic model operations such as [creating](./introduction.md#create), [updating](./introduction.md#update), or [deleting](./introduction.md#delete) records are automatically wrapped in a transaction. This helps in ensuring that any exception that is raised in the context of validations or as part of `after_*` [callbacks](./callbacks.md) (ie. `after_create`, `after_update`, `after_save`, and `after_delete`) will also roll back the current transaction.
 
-The consequence of this is that the changes you make to the database in these callbacks will not be "visible" until the transaction is complete. For example, this means that if you are triggering something (like an asynchronous job) that needs to leverage the changes introduced by a model operation, then you should probably not use the regular `after_*` callbacks. Instead, you should leverage [`after_commit`](./callbacks.md#aftercommit) callbacks (which are the only callbacks that are triggered _after_ a model operation has been committed to the database).
+The consequence of this is that the changes you make to the database in these callbacks will not be "visible" until the transaction is complete. For example, this means that if you are triggering something (like an asynchronous job) that needs to leverage the changes introduced by a model operation, then you should probably not use the regular `after_*` callbacks. Instead, you should leverage [`after_commit`](./callbacks.md#after_commit) callbacks (which are the only callbacks that are triggered _after_ a model operation has been committed to the database).
 
 ## Exception handling and rollbacks
 

docs/docs/templates/how-to/create-custom-context-producers.md

@@ -25,4 +25,4 @@ end
 
 ## Activating context producers
 
-As mentioned in [Using context producers](../introduction.md#using-context-producers), context producers classes must be added to the [`templates.context_producers`](../../development/reference/settings.md#contextproducers) setting in order to be used by the Marten templates engine when initializing new context objects.
+As mentioned in [Using context producers](../introduction.md#using-context-producers), context producers classes must be added to the [`templates.context_producers`](../../development/reference/settings.md#context_producers) setting in order to be used by the Marten templates engine when initializing new context objects.

docs/docs/templates/introduction.md

@@ -226,7 +226,7 @@ Obviously, it is also possible to include partials that don't require any variab
 Templates can be loaded from specific locations within your codebase and from application folders. This is controlled by two main settings:
 
 * [`templates.app_dirs`](../development/reference/settings.md#app_dirs-1) is a boolean that indicates whether or not it should be possible to load templates that are provided by [installed applications](../development/reference/settings.md#installed_apps). Indeed, applications can define a `templates` folder at their root, and these templates will be discoverable by Marten if this setting is set to `true`
-* [`templates.dirs`](../development/reference/settings.md#dirs1) is an array of additional directories where templates should be looked for
+* [`templates.dirs`](../development/reference/settings.md#dirs-1) is an array of additional directories where templates should be looked for
 
 Application templates are always enabled by default (`templates.app_dirs = true`) for new Marten projects.
 
@@ -387,7 +387,7 @@ Context producers are helpers that ensure that common variables are automaticall
 
 For example, they can be used to insert the current HTTP request object in every template context being rendered in the context of a handler and HTTP request. This makes sense considering that the HTTP request object is a common object that is likely to be used by multiple templates in your project: that way there is no need to explicitly "insert" it in the context every time you render a template. This specific capability is provided by the [`Marten::Template::ContextProducer::Request`](pathname:///api/dev/Marten/Template/ContextProducer/Request.html) context producer, which inserts a `request` object into every template context.
 
-Template context producers can be configured through the use of the [`templates.context_producers`](../development/reference/settings.md#contextproducers) setting. When generating a new project by using the `marten new` command, the following context producers will be automatically configured:
+Template context producers can be configured through the use of the [`templates.context_producers`](../development/reference/settings.md#context_producers) setting. When generating a new project by using the `marten new` command, the following context producers will be automatically configured:
 
 ```crystal
 config.templates.context_producers = [

docs/docs/the-marten-project/release-notes.md

@@ -8,7 +8,7 @@ Here are listed the release notes for each version of the Marten web framework.
 
 ## Marten 0.5
 
-* [Marten 0.5 release notes](./release-notes/0.5.md) _(under development)_
+* [Marten 0.5 release notes](./release-notes/0.5.md)
 
 ## Marten 0.4
 

docs/docs/the-marten-project/release-notes/0.2.md

@@ -73,7 +73,7 @@ end
 
 ### Transaction callbacks
 
-Models now support the definition of transaction callbacks by using the [`#after_commit`](../../models-and-databases/callbacks.md#aftercommit) and [`#after_rollback`](../../models-and-databases/callbacks.md#afterrollback) macros.
+Models now support the definition of transaction callbacks by using the [`#after_commit`](../../models-and-databases/callbacks.md#after_commit) and [`#after_rollback`](../../models-and-databases/callbacks.md#after_rollback) macros.
 
 For example:
 

docs/docs/the-marten-project/release-notes/0.3.md

@@ -127,7 +127,7 @@ end
 
 #### Development
 
-* [`Marten::HTTP::Errors::SuspiciousOperation`](pathname:///api/0.3/Marten/HTTP/Errors/SuspiciousOperation.html) exceptions are now showcased using the debug internal error page handler to make it easier to diagnose errors such as unexpected host errors (which result from a missing host value in the [`allowed_hosts`](../../development/reference/settings.md#allowedhosts) setting).
+* [`Marten::HTTP::Errors::SuspiciousOperation`](pathname:///api/0.3/Marten/HTTP/Errors/SuspiciousOperation.html) exceptions are now showcased using the debug internal error page handler to make it easier to diagnose errors such as unexpected host errors (which result from a missing host value in the [`allowed_hosts`](../../development/reference/settings.md#allowed_hosts) setting).
 * [`Marten#setup`](pathname:///api/0.3/Marten.html#setup-class-method) now raises.[`Marten::Conf::Errors::InvalidConfiguration`](pathname:///api/0.3/Marten/Conf/Errors/InvalidConfiguration.html) exceptions when a configured database involves a backend that is not installed (eg. a MySQL database configured without `crystal-lang/crystal-mysql` installed and required).
 * The [`new`](../../development/reference/management-commands.md#new) management command now automatically creates a [`.editorconfig`](https://editorconfig.org) file for new projects.
 * A new [`root_path`](../../development/reference/settings.md#root_path) setting was introduced to make it possible to configure the actual location of the project sources in your system. This is especially useful when deploying projects that have been compiled in a different location from their final destination, which can happen on platforms like Heroku. By setting the root path, you can ensure that your application can find all necessary project sources, as well as other files like locales, assets, and templates.

docs/docs/the-marten-project/release-notes/0.4.md

@@ -134,7 +134,7 @@ end
 * The hash of matched routing parameters that is available from handlers through the use of the `#params` method can accept symbols and strings when performing key lookups.
 * The [GZip middleware](../../handlers-and-http/reference/middlewares.md#gzip-middleware) now incorporates a mitigation strategy against the BREACH attack. This strategy (described in the [Heal The Breach paper](https://ieeexplore.ieee.org/document/9754554)) involves introducing up to 100 random bytes into GZip responses to enhance the security against such attacks.
 * A new [`before_render`](../../handlers-and-http/callbacks.md#before_render) callback type is now available to handlers. Such callbacks are executed before rendering a [template](../../templates/introduction.md) in order to produce a response. As such they are well suited for adding new variables to the global template context so that they are available to the template runtime.
-* All handlers now have access to a [global template context](../../handlers-and-http/introduction.md#global-template-context) through the use of the [`#context`](pathname:///api/0.4/Marten/Handlers/Base.html#context-instance-method) method. This template context object is available for the lifetime of the considered handler and can be mutated to define which variables are made available to the template runtime when rendering templates (either through the use of the [`#render`](#render) helper method or when rendering templates as part of subclasses of the [`Marten::Handlers::Template`](../../handlers-and-http/generic-handlers.md#rendering-a-template) generic handler). This feature can be combined with the [`before_render`](../../handlers-and-http/callbacks.md#before_render) callback to effortlessly introduce new variables to the context used for rendering a template and generating a handler response.
+* All handlers now have access to a [global template context](../../handlers-and-http/introduction.md#global-template-context) through the use of the [`#context`](pathname:///api/0.4/Marten/Handlers/Base.html#context-instance-method) method. This template context object is available for the lifetime of the considered handler and can be mutated to define which variables are made available to the template runtime when rendering templates (either through the use of the [`#render`](../../handlers-and-http/introduction.md#render) helper method or when rendering templates as part of subclasses of the [`Marten::Handlers::Template`](../../handlers-and-http/generic-handlers.md#rendering-a-template) generic handler). This feature can be combined with the [`before_render`](../../handlers-and-http/callbacks.md#before_render) callback to effortlessly introduce new variables to the context used for rendering a template and generating a handler response.
 
 #### Templates