Skip to content

Commit

Permalink
Merge pull request #253 from stepchowfun/v0.0.5
Browse files Browse the repository at this point in the history
Release v0.0.5
  • Loading branch information
stepchowfun authored Oct 24, 2021
2 parents c3d8750 + 9c471d1 commit ba63d86
Show file tree
Hide file tree
Showing 4 changed files with 9 additions and 4 deletions.
5 changes: 5 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,11 @@ All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [0.0.5] - 2021-10-23

### Added
- Introduced the `deleted` fields feature.

## [0.0.4] - 2021-10-16

### Fixed
Expand Down
2 changes: 1 addition & 1 deletion Cargo.lock

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion Cargo.toml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
[package]
name = "typical"
version = "0.0.4"
version = "0.0.5"
authors = ["Stephan Boyer <[email protected]>"]
edition = "2021"
description = "Algebraic data types for data interchange."
Expand Down
4 changes: 2 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -365,7 +365,7 @@ The index is a non-negative integer which is required to be unique within the ty

#### Deleted fields

If you delete a field, you must be careful not to reuse that field's index for any new fields as long as there are messages still containing the deleted field. Otherwise, the old field would be decoded as the new field, which is likely to result in deserialization errors and is almost certainly not what you want. To avoid this, you can reserve the indices of deleted fields to prevent them from being reused. For example, if we delete the `ip_address` and `owner` fields from the `Device` `struct` above, we might wish to reserve their indices as follows:
If you delete a field, you must be careful not to reuse that field's index for any new fields as long as there are messages still containing the deleted field. Otherwise, the old field would be decoded as the new field, which is likely to result in deserialization errors and is almost certainly not what you want. To avoid this, you can reserve the indices of deleted fields to prevent them from being reused. For example, if we delete the `ip_address` and `owner` fields from the `Device` `struct` above, we can reserve their indices as follows:

```perl
struct Device {
Expand All @@ -375,7 +375,7 @@ struct Device {
}
```

Typical will then prevent you from introducing new fields with those indices.
Typical will then prevent us from introducing new fields with those indices.

### Built-in types

Expand Down

0 comments on commit ba63d86

Please sign in to comment.