Edit 2018-05-31: Auto-senescence terminology changed to “end-of-support halt”.
Starting in May the Bitzecdevelopment effort will institute a new release policy. There are a few immediate take-aways for users:
- We’ll release monthly on the third Tuesday, starting with 1.0.9 on May 16th.
- Each release starting with 1.0.9 will become deprecated 4 months after its release date. [1]
- We may deprecate releases earlier than this schedule to mitigate security vulnerabilities.
This is an aggressive upgrade schedule and if it doesn’t work for your case, we’d love to hear from you as soon as possible. This is all you need to know as a user, and the rest of this post describes our rationale and some protocol upgrade details.
Better Safety and Quality
Since our launch we’ve used a tight three-week release schedule. We’ve shipped every release within a couple of days of the target date, with the exception of the last postponed 1.0.9 release and an 1.0.8-1 hotfix release.
Our new process has slightly more time between releases. We’ll use this extra time to add more thorough pre-release and package testing, have a retrospective meeting for each release, and begin per-release coordination for each of our longer term roadmap priorities.
Clearer Coordination
An essential change with this new policy is an explicit release lifecycle, the most important parts of which are the release date and the deprecation date, about four months later on the 4th third-Tuesday after the release.
For active releases which have not yet reached their deprecation date, we make our best effort to provide security fixes, follow up to bug reports, avoid disruption on the production network, and help users to upgrade to the latest release. For deprecated releases the only help we promise is in upgrading to the latest release.
In order to codify this cycle, we even intend to introduce a feature called end-of-support halt (previously called “auto-senescence”) starting in 1.0.9 which will cause nodes to automatically exit when they detect they’ve reached their deprecation phase. This feature will always have an opt-out, since (as discussed below) our goal is to give users their own choice, not to coerce or control them.
An important side-note: this policy is defined entirely in the context of a single release, so a user does not need to know anything about our future releases or our new policies for those releases in order to understand this policy for their own installation.
User autonomy: deprecation vs auto-upgrade
We consider user choice to be a paramount value to protect. Although this may sound abstract or overly dramatic it directly affects our technical design choices and plays out as our choice of a deprecation approach, rather than an auto-upgrade approach.
Auto-upgrade of apps has become widespread, because of numerous advantages. One of the most important advantages is in ensuring old software is rare so that vulnerabilities and technical debt are removed from the network thus making the whole safer.
Meanwhile, most users rely on default behavior, and a default auto-upgrade puts them de facto under the influence of a sole group of application developers. Most people believe this is fine, and while it often has been, we believe we’re seeing a deep shift in de-facto governance due to these kinds of technological developments.
We prefer deprecation rather than auto-upgrade, where users must themselves choose either to upgrade to our new releases or other people’s alternatives. We believe this still gives the systemic advantage of removing old software, yet users must explicitly opt-in to each upgrade, and each time is an opportunity to educate themselves and decide on a different fate.
How is deprecation better for Zcash?
Because users and our development community have this agreement, we can begin relying on this schedule for protocol upgrades, security fixes, usability improvements, and removing technical debt.
Once this policy is put in to place starting with our 1.0.9 release in May, we are on track to begin the protocol upgrade to the Sapling feature set.
We’ll also be able to roll out usability improvements, such as payment disclosure and in several months’ time we’ll know that support for those improvements should be widespread, and therefore all wallets and vendors will benefit from ecosystem-wide consistency.
I emphasized “should be” because users may always choose to reject our deprecation policy by editing their local configuration or installing alternative implementations. In that case, we’ll have a clear signal from the user community about their reservations with our direction, so this is one of the key mechanisms of our improving governance.
We’d Love to Hear From You
Please reach out to us with any feedback on this new release policy. You can find us on the community chat or if preferred, reach out directly via email.
Update 2018-05-14: For more information about our release cycle, please read the Release Cycle Update blog post.
| [1] | We’re still determining when and how to deprecate releases before 1.0.9. |