Regular Scheduling For Our Tezos Proposals

Regular Scheduling For Our Tezos Proposals

The teams at Nomadic Labs, Metastate, Marigold, and DaiLambda have participated in a number of joint protocol proposals for Tezos; some of us have been working on the code since the original launch of the Tezos network, and have been involved with updates from Athens through the recent Delphi proposal. Over time, we have gained more and more experience and have learned what practices seem to work best for updates to the Tezos ecosystem.

Up until recently, we have generally focused on releasing proposals when a particular pre-determined set of features have become stable. As the community has matured, and as we have gained experience, we have developed the belief that it is better to release proposals on a regularly scheduled basis instead.

The rest of this blog post describes our reasoning.

In software development, teams are often tempted to release a new version of their code only after a particular set of features is complete. The problem with this approach is that it often leads to releases occurring at longer and longer intervals.

The syndrome tends to work this way: a particular feature is on the must-have list for a release, but is delayed. A developer of another feature worries that because the gap between releases has increased, it is important that their feature be incorporated before the next release or it may not see the light of day for some time. The work to incorporate this change then delays the release further.

Then, other developers notice that releases are happening at longer and longer intervals, and they in turn become more and more worried that if they don’t get their features into the next release, it might be a very long time before users see it.

Soon, a vicious cycle is in progress where releases happen further and further apart, first being delayed by months, and then by years.

One remedy that many projects have found for this problem is straightforward: release code regularly, at scheduled intervals rather than when particular features are complete.

The reason this works is also straightforward. If trains leave a station every ten minutes, few people will be worried about missing a train; there will always be another a few minutes later. However, if trains leave without a fixed schedule and at long intervals, people become very paranoid that when the current train leaves, there might not be another for quite some time.

An important feature of Tezos is its ability to evolve without breaking its own rules. Tezos’ on-chain governance provides a neutral mechanism for stakeholders to coordinate and agree on updates to the protocol and its implementation.

Like many blockchain projects, Tezos is an open-source project with contributors from all over the world but, unlike other projects, it provides a mechanism through which anyone can credibly advance proposals w1ithout facing the typically insurmountable hurdle of coordinating a hard-fork.

Our teams, alongside many other contributors around the world, have historically collaborated on making ambitious proposals for the Tezos project. Going forward, we have decided to collaborate to submit protocol proposals every few months, which is the interval permitted by the Tezos on-chain amendment process. These will incorporate code that has been completed to our satisfaction by the scheduled date, rather than our introducing new proposals only when a predetermined set of features are finished.

The capacity to evolve is a key distinguishing feature of Tezos. With a scheduled releases approach, protocol proposals will occur with a much more steady cadence. We believe that this will, in turn, allow Tezos to gain the features developers and users have requested on a more dependable timeline.


Tezos is obviously made to evolve and this fact should be used to add new features to the protocol and innovate. But an important aspect and I’ve voiced this opinion before, are the repercussion of a protocol upgrade. It’s not just the protocol upgrade itself that needs to be developed, tested and then applied, all the tooling has to be brought up to speed as well.

If there are many breaking changes that impact libraries and other tooling on a regular basis, then this will affect a lot of projects in the ecosystem. As far as I recall there was the discussion about adding a fifth proposal period to account for this, nevertheless the resources in various project need to be available to act on these changes. For projects building on Tezos one can argue this can be attributed to maintenance cost but it’s an additional factor that these projects need to account in their calculations.

I welcome regular upgrade and a clear roadmap, but we need to make sure that not every upgrade has a big impact on all the dependents. A possible option would be to alternate between features and maintenance updates, one contains more changes that could impact a lot of the ecosystem, the other would focus on certain aspect and address urgent issues like Delphi for example now.


I am all for this approach! :innocent:

This is a good beguinning. Consider also to publish a clear roadmap of all your features being developed and their expected ETA to be injected (or at least an aprox. progress line), so the non-core devs and adopters can organize themselves in an even more accurate way.

Specifically, how will this affect the next proposal?

1 Like

One piece of the puzzle is that library and tool developers should write integration tests and unit tests and contribute them to a public repo such as This would, in effect, document the properties of the shell and of the protocol which are depended upon and help identify potentially breaking changes very early in the core development process.


I second everything @pascuin said.

@murbard, integration tests in a public repo make a lot of sense as a public good. The most onerous part of incorporating a new protocol into our tools is dealing with new features so we will still need an upgrade cadence that is reasonable for all tool makers.

That is definitely a sensible approach and would help a lot to speed up the development cycles. One side note, the projects building on these libraries still need to update the dependencies thus requiring resources but having the advantage of a broader time frame.

In any case the outcome of such an approach would definitely strengthen the confidence in the underlying tooling.

Not breaking existing tools (or providing easy migration) is extremely important.

Waiting for the tooling to catch up to the feature set is just pragmatism, there’s not much point in introducing features no one can use.

But that happens naturally and I don’t see much of an issue with the protocol sometimes being ahead of the tooling so long as the tooling eventually catches up.