Tezos breaks a record in the rate of how things become deprecated so quickly

Philosophy and Economics
1

The title is not from me but a quote from a user in a recent conversation about Tezos. Down are other quotes from participants that share similar thoughts like the quote in the title. I have mixed feelings and somehow this sounds a bit true? What are your thoughts about that? One prominent example in the conversation was Truffle, they got annoyed by too many upgrades and left - is that true?

it makes me wonder about the whole self amending concept and how scalable it is when the ecosystem is supposed to grow and adapt itself to these rapid ongoing changes

i had 2 simple private dapps that i abandoned just due to ithaca, which made them totally obsolete + me not having enough time/resources to refactor it all over again

one of the numerous reasons i stopped wanting to run Endless Ways was dealing with fallout from Tezos network upgrades

tezos upgrade cycles are exhausting and, like Joe said above, getting bummed and abandoning projects is a very real risk

It’s still in progress, unfortunately. We’re postponing many features due to too often protocol updates which have a lot of breaking changes, especially Tenderbake.

2 Likes
2

Who is this quote from specifically and can you link to the original post? I think that would be helpful for context.

The ability to innovate quickly can certainly become a hindrance to adoption when that innovation leads to breaking changes.

It would be good if we could poll the community to see how breaking changes have affected delivery teams.

3 Likes
3

I don’t know what kind of discussion you want us to have. Shall we talk about the Ithaca upgrade in particular (and discuss how things could have been done differently to avoid breaking stuff) or about our culture of deprecation in general?

2 Likes
4

That happened in this chat Telegram: Contact @chinstrap_io - some users were discussing the upgrades and tools that dont work due to upgrades. You can look at the conversation. I think its a good idea about the poll to see how it affects teams.

rafoo both your proposals for discussion are great topics. Could be a great discussion with new insights for outsiders that think the way I presented in the opening message or for everyone in general

1 Like
5

I’m not saying I agree with 100% of the above quotes, some of it may also depend on what area you are working in, but I do at least agree with elements of it. Had a similar discussion on Reddit recently asking about hackathons for developer tooling.

On the one hand, its great to see so much effort and research being put in to keep the blockchain tech top tier, and making sure we have the right pieces in place to scale. We’ve shown the world that we can upgrade huge chunks of the chain, and bring in massive new features / changes.

On the other, its frustrating to see new feature + new feature + new feature coming from the core team, while such critical stuff like local forging, michelson SDK’s, wallet creation, encryption, formatting, hashing etc is left up to the community to build from scratch over and over again in different languages.

A post from nomadic went out a few weeks back, talking about all the new layer 2 stuff that will be added in coming protocols. Don’t get me wrong, that all sounds very cool and super useful … but do we need it right now? is increasing the scalability such a massive priority that it needs to be all hands on deck? Personally I don’t think so. I’m writing Swift code for Tezos at the minute and I have to rely on Trust Wallets open source library (which is massive, and incompatible with MacOS for writing desktop apps) in order to create private keys and wallets. I spent days researching how to convert a module of Taquito into something that I could put into an iOS JSContext, so that I can perform local forging. Not only am I hoping that a third party team have duplicated the client code for local forging perfectly, i’m also hoping they maintain it, and I have to manually check for updates and pull them down because its not compatible with my code in its current form. Running through JS also comes with a noticeable performance hit.

I firmly believe the core teams taking a break, and making some of the internals of the client/node available as standalone modules (in C, C++, Rust etc) that all languages can import, is a far more important task than some of the current ongoing upgrades. Dealing with Tezos means dealing with a lot of highly custom, bespoke or advanced topics. I’m not a cryptography guy, I don’t have a degree in computational linguistics or high performance programming. I come form a much more simplistic, higher level / frontend / UI+UX, style of background. Having to spend weeks and months digging through all this stuff is a massive burden. When the Edo protocol was announced that it would be making changes to Michelson, that was extremely costly to teams. There was no tooling or SDK’s provided, only written documentation and example contracts on testnet. Every team had to stop what they were doing and research this new topic and test the hell out of it.

The developer community needs the experts that are building all these core critical features, to make them available, ensure they are maintained, and updated before any proposal is injected. Too much is being expected of the developer community. It feels like the core teams are too focused on the Research aspects of development, and less so on the more production side of things

7 Likes
6

+1. there were a number of reasons why we shut down Endless Ways and one was, in the three months i was single handedly building the tech stack there were two protocol upgrades that meant i had to either re-engineer parts of my code or fix the indexer, and each of these tasks took a couple of days of work.

the recent change to Ithaca broke the way archive nodes worked, which took my indexer down for a week, and i had to completely re-engineer the front-end to talk directly (and slowly) to the blockchain.

looking forward, just the task of keeping the indexer up to date and running - and taping together fixes when things break unpredictably - was an exhausting prospect. maybe it’s fine if you have a 5 person dev team. but i was working alone, and it was already too much even before we’d made it into full-speed public access mode.

1 Like
7

I worry about potential adopters of Tezos choosing other, slower to update chains, for their products, specifically to avoid the risks associated with building a product on Tezos, and then being unable to keep pace with the delivery cycle.

What a lot of companies do to mitigate the risk of not being able to keep up with a frequent delivery schedule, is use LTS versions. Lots of popular open source software, such as NodeJS, Ubuntu, EmberJS, etc., all over LTS versions for stability, which allow adopters to mitigate the risk of having to deal with breaking changes frequently.

I realize that Tezos, as a protocol, can’t really exist in two states, as an LTS version and non-LTS version, but maybe there is a set of core functionality we can recommend developers keep extremely backwards compatible for higher stability. It’s tricky since their is no centralized core development team, but we could try to establish backwards compatibility for core features as a community/cultural norm.

8

Just saw it now in the baking bad discord. All the new updates in protocol are great but I guess most of us - me included - forget that all the teams need to keep up the pace to adapt with new protocol changes

grafik
grafik1226Ă—110 21.3 KB

1 Like
9

LTS is mainnet, go to testnets for unstable networks. Tezos is not a library, it is an instance. Any cloud provider suffers from Platform instance upgrades , Tezos is the same

10

I was only using LTS as an example for users reading this thread who may be less technical. Obviously Tezos isn’t a library.

The point is that users of the Tezos Blockchain are being negatively affected by the upgrade cycle, and need a way to handle this upgrade cycle which doesn’t involve spending many more people hours on updating their libraries and applications.

11

Like we do on Cloud environments, running regularly applications on available testnets would prevent any unexpected behavior. Tezos 3 months of changes is for me veryyyyyy slow changes, I used to deploy several times a week on traditional cloud env … I would recomment to look at test tooling automation more than the Tezos cycles :slight_smile:

12

@Benjamin_Fuentes Maybe I’m misunderstanding you, but it sounds like you are saying all the Tezos developers in this thread who have experienced friction due to the upgrade cycle should just build better continuous testing suites on each Tezos testnet as they emerge.

I would love to hear @damian0815’s opinion on this. Did you as a solo developer have time to create and maintain any continuous testing suite, and if so, did it alleviate your upgrade pains at all?

13

yes, correct. You understood well.

At marigold we have test step on the pipeline to chekc non regression.

On my previous experience, I always put in place non regression test and reports for any build pipeline I had, also end2end functional tests on a real testnet to track any drift. Leveraging gitlab / github automation is removing part of setup cost. I encourage you to do so as a good devops guy.

14

@Benjamin_Fuentes thanks for confirming that I’ve understood your position correctly.

Writing comprehensive tests and configuring automation suites takes time. The more tests you write, and the more complex your automation, the more time it takes.

I don’t think it’s a reasonable position to expect every single small development team, who may not be compensated for their work, to spend the time to write these tests and configure this automation, while also updating these tests and automation suites with each release.

That is an incredible amount of overhead for every single small development team in our ecosystem.

Again, I welcome feedback from @damian0815, since they have experienced this issue first hand.

15

yeah, i 100% agree @noodlestomatojuice .

i would add, as well, it’s not just time, it’s also knowledge. i had a full set of unit tests for the smart contract code itself, but i simply lack the skills/knowledge to be able to have the same thing going for everything else i needed: tezos nodes, indexers for each node, and all the infrastructure necessary to make devops work.

and this is not for lack of trying. i lost a day trying to get a teamcity instance up and running before figuring out it’s not supported on my system.

most of us doing edge-case or experimental (aka interesting) work at the intersection of tech and art and blockchain work in similar ways: we don’t learn complete systems top-down, we chip away at what we don’t know, until we do know enough to make the thing we’re trying to make work.

this is fwiw not the first time i’ve encountered an attitude like Benjamin’s in this space. people making the Tezos infrastructure need to understand that if they want people to use it, they have to be prepared to make it usable for people who aren’t like them. it’s at root a diversity & inclusion issue.

2 Likes
16

Thanks for sharing your friction points @damian0815.

@Benjamin_Fuentes, while I do think having automated tests can help small development teams upgrade in a more frictionless manner, I don’t think tests alone are the solution.

17

Several point here :

  • I am not part of core developers of Tezos. My attitude has nothing to do about it, I am talking as a classical dapp developer here. I can understand your frustration, btw.
  • about knowledge : if you want to use Ligo, I did a training here talking about unit tests (GitHub - marigold-dev/training-dapp-2: Training n°2 for decentralized application). I hope it can help you. I still recommend to have also funtional end2end tests on a real testnet
  • about infra : I really do not understand why you so many issue about infra nodes, etc … You work on a blockchain, your backend is mostly your smart contract, you don’t have really a lot of work on this side
  • about documentation : I agree this is not enough for developers. I started to write trainings, now at Marigold we will try also to do videos on Youtube for developers to help them create dapp on Tezos. FYI, 2 new trainings will be added this summer to cover more features

Please don’t shoot the messenger :slight_smile:

2 Likes
18

@Benjamin_Fuentes, maybe trainings about how to build comprehensive automated tests, that come with some nice boilerplate code and configuration files for popular CI/CD tools would help alleviate upgrade pains.

I still don’t think automated testing is the complete answer though.

1 Like
19

Are the training somewhere on the Ligo website too? Quick looking I could not see it maybe its under Turotials, if not it would be good to place it on a prominent place like “Trainings” so people find it easy.

20

It is under our github repo : Marigold · GitHub

I will immediately request an entry on Marigold website to index it :slight_smile:

Thanks

1 Like