Landscape release flows
21 views
Skip to first unread message
Matilde Park
Jan 6, 2021, 5:42:20 PM1/6/21
to urbit-dev
Dev,
Just wanted to flag some changes to how Landscape development is tested and deployed. As per my previous email in urbit-dev, we now continuously deploy front-end changes to release/next-js. To our QA subset of users we can quickly gather tests and squash issues as they arise before touching the broader network.
I intend to release this branch to the broader network on a recurring rhythm — every 2 weeks is a decent pace for stabilising the work in the branch before broader use.
At the same time, release/next-userspace is adopting a much slower rhythm for full-stack features and changes, going out every 6 weeks, with the last two weeks acting as a polish cycle for introducing and refining the UX of the features we ship.
This leaves a gap for back-end fixes, which often are high-impact, time-sensitive changes. For the time being I advise these PRs to be made as hotfixes to master; but I also think we may want to adopt a weekly cadence for these fixes on their own branch as well.
By pushing each to master we end up with a situation where userspace fixes are deployed as small, precise updates on a regular basis; but I think the ideal we want is to have a predictable rhythm with our userspace and system updates. I welcome suggestions in this regard and will append any decision to this thread and to our documentation more broadly.
Thanks!
—
~haddef-sigwen
https://urbit.org
Just wanted to flag some changes to how Landscape development is tested and deployed. As per my previous email in urbit-dev, we now continuously deploy front-end changes to release/next-js. To our QA subset of users we can quickly gather tests and squash issues as they arise before touching the broader network.
I intend to release this branch to the broader network on a recurring rhythm — every 2 weeks is a decent pace for stabilising the work in the branch before broader use.
At the same time, release/next-userspace is adopting a much slower rhythm for full-stack features and changes, going out every 6 weeks, with the last two weeks acting as a polish cycle for introducing and refining the UX of the features we ship.
This leaves a gap for back-end fixes, which often are high-impact, time-sensitive changes. For the time being I advise these PRs to be made as hotfixes to master; but I also think we may want to adopt a weekly cadence for these fixes on their own branch as well.
By pushing each to master we end up with a situation where userspace fixes are deployed as small, precise updates on a regular basis; but I think the ideal we want is to have a predictable rhythm with our userspace and system updates. I welcome suggestions in this regard and will append any decision to this thread and to our documentation more broadly.
Thanks!
—
~haddef-sigwen
https://urbit.org
Reply all
Reply to author
Forward
0 new messages