CONTRIBUTING.md and CHANGELOG.md includes more information about the

monorepo setup, and changed all Haskell libraries from `0.a.b.c` to
`1.a.b.c` as per the versioning requirements

CHANGELOG.md

@@ -7,18 +7,81 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
-### Added
+- Initial release
 
-### Changed
+### Schemas
 
-### Removed
+#### lbf-prelude
+##### Purescript
+##### Rust
+##### Haskell
+##### Typescript
 
-## v1.0.0
+#### lbf-plutus
+##### Purescript
+##### Rust
+##### Haskell
+##### Typescript
+##### Plutarch
+##### PlutusTx
 
-### Added
+### Tools
 
-- Initial versioning release
+#### Frontend
+#### Compiler
+#### Compiler Proto API
+#### Codegen
+#### Codegen Proto API
 
-### Changed
+### Runtimes
 
-### Removed
+#### Rust lbr-prelude
+#### Haskell lbr-prelude
+#### Typescript lbr-prelude
+
+#### Rust lbr-plutus
+#### Haskell lbr-plutus
+#### PlutusTx lbr-plutus
+#### Plutarch lbr-plutus
+#### Typescript lbr-plutus
+
+## LambdaBuffers v.1.0.0
+
+- Initial release
+
+### Schemas
+
+#### lbf-prelude v.1.0.0
+##### Purescript
+##### Rust
+##### Haskell
+##### Typescript
+
+#### lbf-plutus v.1.0.0
+##### Purescript
+##### Rust
+##### Haskell
+##### Typescript
+##### Plutarch
+##### PlutusTx
+
+### Tools
+
+#### Frontend v.1.1.0.0
+#### Compiler v.1.1.0.0
+#### Compiler Proto API v.1.0.0
+#### Codegen v.1.1.0.0
+#### Codegen Proto API v.1.0.0
+#### Utils v.1.1.0.0
+
+### Runtimes
+
+#### Rust lbr-prelude v.1.0.0
+#### Haskell lbr-prelude v.1.1.0.0
+#### Typescript lbr-prelude v.1.0.0
+
+#### Rust lbr-plutus v.1.0.0
+#### Haskell lbr-plutus v.1.1.0.0
+#### PlutusTx lbr-plutus v.1.0.0
+#### Plutarch lbr-plutus v.1.0.0
+#### Typescript lbr-plutus v.1.0.0

CONTRIBUTING.md

@@ -11,9 +11,9 @@ of preexisting exported entities. If any of this occurs, a major version must be
 bumped. Disregarding this rule can end up in breaking client package updates.
 
 Any changes must be logged in `CHANGELOG.md`, which must comply with [Keep A
-Changelog](https://keepachangelog.com/en/1.1.0/) requirements. Each entry should
-also provide a link to the GitHub issue and/or Pull Request that corresponds to
-the entry.
+Changelog](https://keepachangelog.com/en/1.1.0/) requirements. Each entry
+should also provide a link to the GitHub issue and/or Pull Request that
+corresponds to the entry.
 
 An example entry is below:
 
@@ -22,6 +22,52 @@ An example entry is below:
   [#123](https://github.com/mlabs/lambda-buffers/issues/123)
 ```
 
+## Release flow
+
+In this repository we adopted a flow with multiple release branches, one for
+each major version. This means that users of these packages can point to these
+branches and use `nix flake update` without having to deal with breaking changes.
+These branches must follow the pattern of `v-MAJOR(.MAJOR)` (`v1`, `v2` etc. for
+Semantic Versioning, or v1.0 for PVP).
+
+Furthermore, release versions are pushed as `git tags`.
+
+Stable versions should always be pushed to their respective release branches
+in a reasonable schedule (weekly or monthly depending on the project).
+In most cases this would also mean a release, which requires some additional
+manual tasks:
+
+1. bump versions in package manifest files (*.cabal, Cargo.toml, etc.)
+2. update lock file if necessary
+3. push git tag
+
+## Monorepo versioning policies
+
+If a repository has multiple packages, these can evolve independently and their
+release cycle could be different. All changes shall be contained in the
+aggregated `CHANGELOG.md` of all packages under the appropriate header.
+
+If a Semantic Versioning and PVP are used simultaneously, the first major
+number of PVP must always be 1 (or 0 if in a beta state).
+
+Versioning policies when updating dependencies are well explained in the
+[PVP][pvp] and [Semver][semver] documents, the same rules apply to dependencies
+inside the same repository. In short, if a dependency update does not have any
+effect on the public interface of the upstream package, it can be considered a
+minor or patch release.
+
+> As an example if we have three packages `HaskellApp-v1.3.4.1`,
+> `HaskellLib-v1.3.0.0` and `RustApp-v0.1.0`, we could bump `HaskellApp` to `1.4.0.0`
+> without touching the other two if `HaskellLib` is unchanged. After this, when
+> `RustApp` reaches a stable state, we must jump to `4.0.0` straight away, to align
+> versions. Similarly, if `HaskellLib` is only updated after of `HaskellApp`
+> reached `1.5.0.0`, it must also jump to `1.5.0.0`.
+>
+> In another scenario, if we refactor `HaskellLib` and push a new major version
+> `1.6.0.0`, while `HaskellApp` can update it's dependency of `HaskellLib` without
+> changing its own public interface (e.g. CLI is completely unchanged), it's
+> sufficient to do a minor (or patch) bump from `1.5.0.0` to `1.5.0.1`
+
 ## Acknowledgements
 
 This document was adapted from [tx-village

extras/lambda-buffers-utils/lambda-buffers-utils.cabal

@@ -1,6 +1,6 @@
 cabal-version:      3.0
 name:               lambda-buffers-utils
-version:            0.1.0.0
+version:            1.1.0.0
 synopsis:           Lambda Buffers utils
 data-files:
 extra-source-files:

lambda-buffers-codegen/lambda-buffers-codegen.cabal

@@ -1,6 +1,6 @@
 cabal-version:      3.0
 name:               lambda-buffers-codegen
-version:            0.1.0.0
+version:            1.1.0.0
 synopsis:           Lambda Buffers Codegen
 author:             MLabs LTD
 maintainer:         [email protected]

lambda-buffers-compiler/lambda-buffers-compiler.cabal

@@ -1,6 +1,6 @@
 cabal-version:      3.0
 name:               lambda-buffers-compiler
-version:            0.1.0.0
+version:            1.1.0.0
 synopsis:           Lambda Buffers compiler
 data-files:
   data/**/*.pl

lambda-buffers-frontend/lambda-buffers-frontend.cabal

@@ -1,6 +1,6 @@
 cabal-version:      3.0
 name:               lambda-buffers-frontend
-version:            0.1.0.0
+version:            1.1.0.0
 synopsis:           Lambda Buffers Frontend
 author:             MLabs LTD
 maintainer:         [email protected]

runtimes/haskell/lbr-plutarch/lbr-plutarch.cabal

@@ -1,6 +1,6 @@
 cabal-version: 3.0
 name:          lbr-plutarch
-version:       0.1.0.0
+version:       1.1.0.0
 synopsis:
   Lambda Buffers Runtime library to support working with `lbf-plutus` and `lbf-prelude` packages and Plutarch
 

runtimes/haskell/lbr-plutus/lbr-plutus.cabal

@@ -1,6 +1,6 @@
 cabal-version: 3.0
 name:          lbr-plutus
-version:       0.1.0.0
+version:       1.1.0.0
 synopsis:      Lambda Buffers Runtime library for the `lbf-plutus` package
 author:        Drazen Popovic
 maintainer:    [email protected]

runtimes/haskell/lbr-plutustx/lbr-plutustx.cabal

@@ -1,6 +1,6 @@
 cabal-version: 3.0
 name:          lbr-plutustx
-version:       0.1.0.0
+version:       1.1.0.0
 synopsis:
   Lambda Buffers Runtime library for the `lbf-plutus` package and the PlutusTx backend
 

runtimes/haskell/lbr-prelude/lbr-prelude.cabal

@@ -1,6 +1,6 @@
 cabal-version: 3.0
 name:          lbr-prelude
-version:       0.1.0.0
+version:       1.1.0.0
 synopsis:
   Lambda Buffers Runtime library for the `lbf-prelude` package