A new development era for DigiByte
I can’t tell you how thrilled I am to finally be able to let everyone know about this great next phase in the history of DigiByte, which sets us up to not only live up to our billion-dollar market capitalization, but future-proofs the foundations of the project for growth well into the future!
This has taken a while to get here, but we’ve been quietly working away in the background, as we evaluated where we are and took a step back, it became important to review and confirm all that is so important to the DigiByte project.
I would even go so far as to say this is one of the most important changes in DigiBytes history: Changing how development is done.
This was implemented after significant feedback and review from a large number of broader stakeholders involved with the DigiByte blockchain, both developers and advocates. We’ve come to a realization that we needed a thorough, professional, reliable, and standardized process for code-review, bugfixes, feature improvements, and especially protocol upgrades. The rigorous checks and balances that this process brings are industry-leading. This high-calibre development environment will enable participation in the DigiByte project with contributions by other experts and new-comers alike, ensuring the utmost excellence and accountability going forward.
Through this reflection, it has not only reinforced DigiByte from a technological perspective, but also strengthened the relationships of those involved at a broader level. As a by-product it has created a more efficient, effective, and trusted environment for meaningful discussions and idea generation.
What inspired these changes?
My excitement is underpinned by us now following the Atlassian Gitflow Workflow method, and I want to show you a little bit of an example of this.
In the past, a number of people could make changes to the README, keeping it updated etc. This was really nice for us from a “low touch” administrative perspective. The users committing to GitHub were basically “trusted” to do the right thing.
However, there was less accountability, and less reviewing of changes that went into DigiByte. Although this wasn’t abused maliciously, due to the significant growth DigiByte has witnessed, there comes a time where it’s prudent to simply say “This is for the best of the project” and make a change.
As such, we have put that stake in the ground, and made that change!
I appreciate that there were so many participating in these broader improvements, and their involvement has been invaluable. I do want to say a special thanks to GTO90 for spearheading this development process initiative in particular, and for being the driving force behind it. There’s certainly been some bumps along the road but what we have now is basically the “ideal” scenario in every way thanks to his implementation of these methodologies, with Continuous Integration testing coming very soon.
What are these improvements?
Not only are we taking a leaf out of the Bitcoin Core playbook, we wanted to take it a small step further in terms of tidiness / accountability. This is the difference between Bitcoin Core contributing vs the Gitflow Workflow process.
Yes, this new process requires slightly more administrative work than even the Bitcoin Core contribution process, BUT it’s for the better!
The difference with Bitcoin is that some maintainers contribute directly against Master, and other contributors / developers make pull requests against the Master branch. With DigiByte and the Gitflow Workflow, nobody can make commits directly at all, and instead all commit against a Develop branch.
Previously for DigiByte where a number of people could commit directly to the codebase, that ability is completely gone.
The only way code is now changed is:
- An atomic pull request is made
- Against it’s own feature-branch
- Which is reviewed by multiple other developers (You can’t “review” your own work, naturally)
- And then merged into the develop-branch
- That’s merged back in to a release-branch when a release is made
- And it’s all then merged back in to Master after a release has taken place
The idea being that your Master is always the “current finalized release” with release-branches remaining for historical purposes, and develop-branch is where all the new / fun stuff takes place!
Now, while this is very similar to Bitcoin Core requirements, what we are doing now for DigiByte with the Gitflow Workflow is slightly more stringent, and I agree with all the developers involved that this is genuinely the best way to proceed, and will truly set DigiByte apart from so many other projects, driving the quality of what DigiByte does to the next level like we’ve not seen before!
A look at the Gitflow process:
We have some examples of this process already taking place that you can see.
Barry and Yoshi have been hard at work with the DigiByte built-in unit tests, and they’re making HUGE progress on this.
The unit tests are baked into Bitcoin Core, that anybody can run as basically a check to go “Yeah, looks good, everything is working as expected”. Some time several years ago, DigiByte deviated sufficiently from the Bitcoin Core codebase (figures, right?) to the point where the unit tests basically broke and never got resolved prior to release. As of DigiByte 7.17.2, they’re still not working. However, this is all changing as we move towards DigiByte version 8.
Despite prior work being done on DigiByte version 8 by Barry, the developers have basically all agreed that given the absolutely MASSIVE scope of the release, it’s best if we take a step back, rewind a little, and follow this Gitflow Workflow process for DigiByte version 8, beginning by fixing up these long outstanding built-in tests.
This is why there’s been less DigiByte update videos from me recently on the topic, because the development team are wanting to do their best to do this “the right way” and uphold themselves all to a much higher standard, with all the code reviewed by multiple people, starting by fixing these unit tests.
As such I would refer you to Pull Request #11 — Fixing blockchain_tests for DigiByte Core.
Barry has corrected the first part of the unit tests, in particular the original difficulty for DigiByte is lower due to us using Scrypt rather than SHA256. You can see that GTO90 acknowledged the tests but had not himself tested them at the time, with a “utACK” (Un-Tested Acknowledgement). It was then tested by Gary and Yoshi, both with an “ACK” (Acknowledge / approve the changes) and it was then merged into the “develop” branch.
The importance of this cannot be overstated: This is how the community can participate in these discussions, allowing any voice to be heard, concerns validated, and opinions listened to.
We’ve already seen a lot of good come out of this method, with other underlying things being picked up along the way to be sorted and resolved. The end-result being that although this will take slightly longer, DigiByte Core itself will have higher-level organization compared to most blockchains out there in terms of the codebase review.
What are the implications for DigiByte 8 release date?
I genuinely can’t say, I simply don’t know.
Once the Unit Tests are all finished, from there we’ll pull in the upstream Bitcoin Core code based on 0.21 most likely.
After this has been done, we can then review the algorithm replacement proposals to strengthen and enhance the blockchain security. Discussion can take place on the GitHub pull requests at that time too, not just from the developers of course (this is the case, at any point in time) but from the broader DigiByte community.
It’s the perfect opportunity to voice your thoughts around which algorithms you’d like to see replaced, or even to say that you don’t think X algorithm should be implemented (though you’ll naturally be expected to be able to state your reasoning and articulate your perspective sufficiently). You can even leave your thoughts around which algorithm should be replaced too. This is because although an initial pull request is being made, it can still be edited and further tweaks reviewed prior to acceptance into the codebase.
After that (or, concurrently alongside it) there will be additional features / improvements / tweaks / bugfixes / performance enhancements which will also all be made as pull requests that I would encourage you to participate in the discussion around.
I mentioned recently in the Swapzone AMA that there was a number of things that had already been worked on, which have taken a bit of a back-seat while we go through not just setting up this newer / stricter process, but also setting up the ground-work for this next release so it gets to the place where we CAN actually adhere to it and implement (or reject even!) all these fancy new features. This could all take a while to go through but it’s a process we all agree needs to really take place, a “growing up” of DigiByte if you will.
IF you’re a coder, or even sufficiently skilled at compiling software, I’d encourage you to give these a whirl as well and jump on and test them, help the team out even prior to them being merged into a new release.
Otherwise, feel free to lurk / watch, or even just react with the emojis when the developers comment that they’ve tested and approved a pull request. The more input we can have going into DigiByte version 8, the better!
I hope you’re as excited as I am for this new process that we’re following for DigiByte, and if you’ve made it this far then I’m sure you’ll agree that this is for the best for DigiByte as a project and will take the codebase to a whole new level in terms of quality / review. We made do with what we had for a long time, but as we’re attracting more and more incredibly talented developers it makes sense for us to utilize this opportunity to uphold the highest possible standards for DigiByte.
