Testnet DayBreak Release Cycle: Explained

New development planning encourages consistent tech releases every 3
weeks
Key Takeaways
- Technical team switches to Release Cycle development planning
- Development update on GitHub every three weeks
- Tech savvy users will be able to interact before deployment on testnet
- First release on __Wednesday, the 13th of April

Testnet DayBreak is live and the response so far has been profound.
Thousands have interacted with our network, Block Explorer, and CLI
Wallet already. And DayBreak’s growth continues every day. Existing
features are always subject to improvement; planned features are always
inching closer to implementation onto testnet; and technical wrinkles
will always be ironed out to ensure a smoother experience for users.

With this in mind, Dusk Network’s technical team is adopting a new
Release Cycle development planning that will benefit both developers and
the community.

Release Cycle Explained: Every Three Weeks

Expectations on releases are currently based on milestone deadlines,
also known as Waterfall planning.

For example, when we’re working on the CLI Wallet, we might first
determine the number of issues there are. Then we determine the amount
of time we’d need to close those issues. At the end, we settle on a
deadline and a public release date for this new version.

Such scheduled version releases can cause issues, both for the
development team and the community. If any of the issues or their
resolution cause an unexpected incompatibility, the entire schedule is
immediately thrown off and a delay has to be announced.

Instead, Dusk Network will adhere to a Release Cycle planning that will
see a development release every three weeks on GitHub, which improves
efficiency and ensures releases are published painlessly.

For example, when we’re working on the CLI Wallet, instead of providing
a deadline for a new version release, we will be continuously working on
it with verifiable documentation of work, published on GitHub every
three weeks.

Certain edge cases, such as hotfixes of vulnerabilities, are not
beholden to the scheduled Release Cycle, but will be resolved ad hoc.
They will take precedence and are considered extra releases that do not
need to follow the schedule. Interruptions of the schedule will only
occur in the case of national holidays, special events, or the
prioritized release of unrelated news.

What Does This Mean For The Community?

For the community, the benefits include no postponement of deadlined
releases, and predictable update patterns, which in turn helps the
developers. After all, developers will be able to prioritize certain
tasks that take less than three weeks but might not be part of a forced
deadline milestone development.
The Release Cycle approach is strictly a way to provide a consistent
shape for publication of our work in the clearest terms possible. They
are not deadlines to be made, nor are they tied to specific development
sprints.__

This new development approach does not affect the way Dusk Network’s
marketing operates; it is a key move towards shipping code faster and,
in addition, minimizing delays of announced news. Significant additions
to DayBreak or its derivatives will be given the spotlight by the
marketing team in dedicated documentation, be it a blog article to share
or a resource paper for the community to consult.

How Can You Get Involved?

‘Release’ does not mean immediate deployment on testnet. This allows us
to give GitHub users the opportunity to install, interact, and test
anything that sees release on the Dusk Network GitHub. In fact, we
highly encourage you to do so. Our community is vital to the network in
many ways, and the ability of the public to provide feedback on releases
is paramount.

We ask any users who have found an issue with any newly released
features to contact us directly [email protected]. Provide your GitHub
username so we can add you to our security advisory for further
discussion. We always aim to respond as swiftly as possible.

What We’re Working On

These Release Cycles published every three weeks on DayBreak’s continued
progress aren’t indefinite. Our main goal is to document the evolution
from DayBreak Launch to DayBreak 2.0, the version necessary to usher in
the next phase: Incentivized Testnet. To get there, implementation and
optimization of a host of elements need to be accounted for, including
the following:

As this new planning is enacted, we’ll start to gradually adopt the
release cycle on our GitHub repositories, starting from the Wallet-CLI
and eventually implement it on all repositories related to testnet
DayBreak.