Skip to content

Latest commit

 

History

History
35 lines (27 loc) · 2.01 KB

DEVELOPMENT_CYCLE.md

File metadata and controls

35 lines (27 loc) · 2.01 KB

Development Cycle

This project follows a regular releasing schedule similar to the one used by the Rust language except releases always follow the latest bdk release by one to two weeks. In short, this means that a new release is made at a regular cadence, with all the feature/bugfixes that made it to master in time. This ensures that we don't keep delaying releases waiting for "just one more little thing".

After making a new bdk-ffi release tag all downstream language bindings should also be updated.

This project uses Semantic Versioning, but is currently at MAJOR version zero (0.y.z) meaning it is still in initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. Until we reach version 1.0.0 we will do our best to document any breaking API changes in the changelog info attached to each release tag.

We decided to maintain a faster release cycle while the library is still in "beta", i.e. before release 1.0.0: since we are constantly adding new features and, even more importantly, fixing issues, we want developers to have access to those updates as fast as possible. For this reason we will make a release every 4 weeks.

Once the project reaches a more mature state (>= 1.0.0), we will very likely switch to longer release cycles of 6 weeks.

The "feature freeze" will happen when bdk releases a release candidate. This project will then be updated and tested with bdk release candidates until a final release is published. This means a new branch will be created originating from the master tip at that time, and in that branch we will stop adding new features and only focus on ensuring the ones we've added are working properly.

To create a new release a release manager will create a new issue using a Release template and follow the template instructions.