560
Versioning
complete
Ben Haefele
The ability to save and revert back to previous versions of your app's design. Your Collections and user data will not be changed when you restore previous designs, only your screens, actions, components, etc.
Josh Johnson
complete
We just launched Design Versions! Read all about it and watch the launch video here: https://adalo.canny.io/changelog/launched-use-design-versions-to-save-and-restore-your-app-design-changes
Josh Johnson
complete
We just launched Design Versions! Read all about it and watch the launch video here: https://adalo.canny.io/changelog/launched-use-design-versions-to-save-and-restore-your-app-design-changes
Bruno Ribeiro
Josh Johnson: Nice! I have been using it, works flawlessly. But Josh, please, give me an answer this time. Based on how many times I comment and ask you about it, you already know how much I and others need external user collection to be completed along with the external user auth beta process. I know you are really on the dev team. They may not be prioritizing that now, but you guys did such impressive work with the location feature that I believe you can quickly drop this feature. It´s been one year since you started the external user authentication beta process. I have significant projects that rely on it, and using workarounds is never the best way to deliver MVPs, so please help me with that.
Josh Johnson
Hey folks! We’ve got something for you to try out if you’re interested. We’re calling it Design Versions and we’d love for you to help us test it. If you’re interested, this form will tell you all about the feature and allow you to sign up for the beta. Note that you'll need to be on a paid plan to test Design Versions. Thanks! https://adalo.typeform.com/to/YjTUI1Mr
Bruno Ribeiro
Josh Johnson Cool. Just Signed, Thanks. By The Way, I am part of other Beta tests for external user auth, which is taking more than a year now. I wish we could finish it by implementing user collection, it is crucial for my apps. I applied a workaround but is never perfect, you know!
M
Mark Murfitt
Josh Johnson: Hey Josh, I received the email asking if I wanted to be part of the beta, and while I'd love to help I'm a little nervous where it says to use it on a test app, which I don't have. We only have our Live app..
Sadly I'm going to have to duck out on this one unfortunately :(
Paul H
Josh Johnson: Josh, just trying it out, it is very helpful!
So one suggestion would be to add a "save to current version" button. I think the way it works now is you need to make changes then save a new version. It might be better to be able to create a new version, make changes, then save the changes to the version that was created, rather than the other way around.
Hope that makes sense.
Josh Johnson
in progress
Josh Johnson
planned
We're doing research and early scoping right now on a versioning system. More specifically, a way to easily save the state of your current screen designs in the editor and easily revert to older versions. Our current thinking is that the first release of this would not touch your collections or data and would be focused on screens, components, actions, styles, etc.
Paul H
Josh Johnson: Just in case you're soliciting feedback... This would be useful from a purely design perspective - being able to undo levels of edits and have an edit history.
But what would be much, much more useful and important would be production/live and dev/test versions where one version is in production (published) while the other one is used for dev and doesn't affect live. When ready the dev version could be pushed to prod (published). IMO this would be MUCH more useful than simple versioning. This would allow testing on live (or test) collections before publishing.
Versioning and live/dev environments both seem to be mentioned in this thread, so I think it's appropropirate to raise this here. Perhaps see what the community prefers (if planning is early enough)?
Josh Johnson
We're looking into this for later this year as well. I'd like to understand your use case a bit more. Is your use case for web apps specifically (since native apps have builds that sort of serve this purpose)? Also, you specifically mention collections. When you say you want a "dev version" do you mean of your app's design and screens or do you mean that you want a dev database with only your test data in it? I'm sure the answer is both but if you had to prioritize, which is more important to you and why? Thanks! This helps.
Zechari Wood-Hillman
Josh Johnson Paul H: this could force users to update the app before any usage can be done upon making the dev published to prod. Kind of like how the Amazon flex app forced its drivers to update the app when an update is published before they’re allowed to make deliveries or access the app in any way.
It would be beneficial
Paul H
Josh Johnson: (Sorry I didn't see this until now)... So for web-apps, the use case is obvious, but for native apps, it would be useful to have in-production stable code, so that we can continue development on new features in the dev environment, but if there are any bugs in production code, they can be fixed separately and we don't have to worry about other changes interfering (for example). Also I think it's good practice to have prod code separate from dev code (using the word code to mean Adalo here :)).
Seperately have a production and test database is useful, but I think it's easier to manage seperate test and real data in a database (you can identify and account for test data, at least in the apps I'm building). So if I had to prioritize it would be two code states before database.
Hope that helps!
Josh Johnson
Paul H: Yes that helps a bunch. Your prioritization makes perfect sense to me and is how I think about it too. Thanks!
Paul H
Josh Johnson: just a bit more why I think this is so important...
I'm integrating with Stripe (my own Custom Actions) and need to be able to have live and test API calls. Once my app is live, I can't easily use test APIs (otherwise I need to start maintaining API keys and URLs on a customer basis), so having the ability to use different API keys/calls in production and test would be a lifesaver.
It hit me over the weekend how important this is. Once I publish a production app, then publishing new TestFlight apps means that my production app is going to end up wildly different to whatever the current Editor version is, making it very hard to track differences (again for testing customer feedback, bug fixes, etc). I think it goes without saying that having a nocode equivalent of something like Github would be great in this respect.
Floris de Schrijver
CTRL or COMMAND + Z works (a bit) - but what would be very useful to consider is a publish button. When I develop changes they are immediately live. That's a true mess. Now I create a duplicate op my app and do changes there, but that doesn't work smooth all the time.
Travelite 360
We are already able to save copies of our different app versions and revert back to them.
Josh Johnson
under review
Floris de Schrijver
Ben Haefele thanks for creating this feature, I think it would be a must to not edit in the live version but to edit in staging. Do you think this will be possible in this feature? Or any ideas for a workaround?
Athylla Bastos
Amazing!!!!
Tony Dehnke
Elementor has a pretty nice setup for this (Wordpress plugin) if you are looking for inspiration Ben Haefele
Load More
→