Kicking off a new thread to announce updates to the Version Control feature that we will be releasing over the coming months.
We realize the Version Control feature is really important for teams and products that are looking to scale on Bubble. While the feature has gone through some iterative improvements in the past, we also recognize that it is not reliable enough for production use. We hope to change this and turn the Version Control feature into another powerful tool in a Bubble developers toolkit.
To do this, we have a two-pronged approach. The first is to improve the reliability of the feature by improving the algorithm and test coverage. The second is to improve the overall user experience and feature set to make it even more powerful. As many of you know, most of the Bubble business is run on a Bubble app. As such, the north star for this Version Control feature is to create something that we are proud of and confident using in-house to manage the complexity of developing a very large production application.
The reliability work is well underway - @zoe1 has been spending a lot of time focused on this and has already tackled a number of known issues and bugs. Research into the next phase, improving the user experience, has started and we are very excited for some of the planned updates.
Thanks everyone and looking forward to future announcements!
To kick things off, we recently updated the Version Control feature to automatically create a save point right before a version is merged. This new save point has been really helpful internally in terms of debugging bad merges, but now also allows you to easily revert a version to right before a merge in case things didnât work out as expected.
Youâll find this new save point in the version history modal - example below.
Sure this is helpful. But with all the issues stemming from version control - including losing DAYS of work, multiple times, due to the undocumented ârulesâ of hierarchy and version control - this first update just falls flat to be honest.
(To be clear, this update would not even help recover work that is lost to version hierarchy issues. And thatâs just one of many problems.)
Version control is broken in many ways and has been broken for quite a while. We have to put WAY too much thought into over-managing versions so we donât step on any known land mines - and we find new landmines in version control rather often.
And getting right to Emmanuelâs core value of getting as many people as possible building on Bubble, we simply cannot hire entry-level Bubble developers because version control is broken. It is simply impossible to manage contributions from less experienced devs with version control in its current state.
And we have had a LOT of applications from entry-level devs we just have to turn down. Itâs heartbreaking.
It doensât help yâall or us to stay quite, so I hope this is helpful. The value Bubble delivers still far, far outweighs this negative, but let me tell you, version control is just frustrating and really, really worrying right now.
This is helpful feedback, and definitely hear your frustration. I think everything you said is spot on and we want to change that with the updates we plan to make in the near future. Version control should be an asset, not a liability.
@nick.carroll Iâve heard you guys say many times that the bubble business is created within bubble itself, out of curiosity can you explain how far that extends?
Do you guys just have an internal CMS, bug tracking, support tracking, website, template store, and similar created using bubble or are parts of the core builder actually built with bubble as well? Would love an elaboration to cure the curiosity.
Great question! Essentially everything outside of the app editor itself is built on Bubble - ie internal cms, website, template store, academy page, and marketing pages (as you mentioned).
We recently received a question asking if we had any recommendations about how to use the version control feature as it currently is. We thought it might be helpful to share these responses with everyone and this thread is a great place to do so!
We first wanted to address some information about what actually happens when you add changes from one version to another. When adding changes from one version (say Version 1) into another (say Version 2), here is how we determine what updates will be made and what conflicts will be generated:
If something (whether it be an element, an action, a propertyâŚ) has been updated (or added/deleted) in Version 2 but has not changed (or never existed) in Version 1 then that thing should not change in Version 2 after you add changes from Version 1 into Version 2.
If something (whether it be an element, an action, a propertyâŚ) has been updated (or added/deleted) in Version 1 but has not changed (or never existed) in Version 2 then that thing should be changed in Version 2 to match the updates that were made to this thing in Version 1 after you add changes from Version 1 into Version 2.
If something (whether it be an element, an action, a propertyâŚ) has been updated in both Version 1 and Version 2 and the updates in each version are different from one another, then when you add changes from Version 1 into Version 2, there will be a conflict raised in Version 2 for the particular thing that has been updated.
When adding changes from one version into another, there may be many changes that have been made to one or both versions since the last time these two were synced up. In that case, for every change detected, the above comparison will be made to determine what the outcome of adding changes from Version 1 into Version 2 should be.
When comparing the two versions to see what has been updated, we do not simply consider all the differences between the two versions. Instead, we actually use a snapshot of what the version that you are adding changes from was the last time these two versions were synced. The time when these two versions were last synced gets updated each time you add changes from one version into another. As a result, the next time you add changes from Version 1 into Version 2, we will not be applying again the changes that had already been considered the previous time you synced the versions. Hence, if you try to add changes from a version into another version without having made any updates to either version since they were last synced then nothing will happen.
We also wanted to share some recommendations about how to use this version control feature.
In general, we recommend keeping your Development version as a âmainâ version that you will add changes from other versions into, create other versions from, and deploy to Live.
If you want to create a new feature or a quick fix, our recommended approach would be:
Create a new version named after the feature you are working on from Development
Work on that new version and, when ready, add the changes from that version into Development
Check in Development that your changes were successfully added and that everything works as expected
Please visit all of the pages that could have changed after the sync in your editor to make sure the updates have been made (some elements or issues might take a little bit of time to appear for large apps).
If you notice that anything was not added then please reach out to our team so we can investigate this situation as part of our ongoing work to improve the reliability of this feature
Deploy your Development version to Live
Delete the feature version you used and for the next features/fixes, create versions off of the updated Development version
We recommend using this approach of a version per feature rather than a version per developer because, in general, things get more complicated the longer different versions exist in parallel, differ from one another, and get changes added from multiple other versions.
Following a similar reasoning, we recommend that the lifetime of versions (other than Development and Live) be kept as short as possible.
We also recommend that if you are working on a fix or feature in one version, that you do not edit the relevant items (elements, workflows, pageâŚ) in another version. This will help to limit the number of conflicts that are raised when syncing the two versions.
We recognize that this approach might not work in every case but these are some general recommendations that we would make.
I hope this was helpful. Weâll continue to keep this thread active as we improve this feature!
We are experiencing strange behaviors since February 8th. As it was mentioned:
we are creating new versions for each new feature or quick fix, but recently it has had reliability issues.
Deleting a Version
Creating a Version
Accessing a Version
After closing my browser and waiting 20-30 mins I can finally access the newly created Version, but this is concerning whether version control is actually stable.
Weâve finally been able to reproduce this issue consistently and a fix is underway. It was a regression introduced about a month ago by a completely unrelated infrastructure bug fix. We will also be adding more tests to basic version control functions to prevent this from happening in the future. Thanks all.
Hey @nick.carroll having another recurring issue - Iâve filed a few different bug reports, but think you should be aware: when merging from a separate version into development, very frequently elements either (1) get dropped, (2) get weirdly duplicated (i.e. they show up twice in element tree but then when selecting one of them, it selects both of them).
This has been happening lately in particular with reusables: if I build a reusable in the other version and merge it back to development, the reusable doesnât come through, and then I get an âapp levelâ error saying âthis reusable cannot be foundâ. Strangely, the name still appears in the list of RUs, but when I click on it it takes me to index.
