Was looking for a previous version in order to revert to, duplicate, then revert back to current in order to get something from an older version.
For the first time, I noticed that it only shows the last 10, though we have had significantly more than 10. You can see in the 2nd image, if I go to the history comparison tool, it lists all of our previous releases in that dropdown -- but in the releases tab itself, it's just the last 10. I refreshed, changed environments, and checked that other apps are showing the same (last 10 only).
Is that something new that Retool only shows the last 10 or is that a bug?
And a request -- I would love an easier way to clone a previous version. Something like this from Google Docs, where you can quickly clone the previous version. Is there a way to do that with releaseVersion?
I'd like to second this - The live version of one of my apps is more than 10 versions old and I need to go back to edit that version to review some queries that I've since deleted.
Just wanted to check the status of this. We use one of our old app versions as a fallback so need to maintain access to it. Is there a way to make a specific old version visible?
No updates yet, but you can preview any release using URL params. For example adding ?_releaseVersion=0.2.4 to the end of the path to my app previews that version. If you're unsure of the path, try previewing one of the releases listed in the history and updating the version number in the url. Let me know if that helps for now!
I'm also curious about the status of this one — I've had to essentially permanently adjust the way I release in order to avoid potential rollback limitations due to what now feels like a permanent regression.
I don't feel like I release too often, but generally I do after one or more discrete changes (conceptual changes, not like literal changes e.g. move an element partially, release, move it further, release ), depending on their substance. Sometimes I group little, incidental changes together, other times I'm doing feature work that is exploratory or might present issues if something goes wrong.
For larger features in heavily used apps, it's very possible that I have several if not close to 10 unpublished releases awaiting additional testing before I feel ready to publish.
As such, I like to have clear releases to which to re-publish/roll back in the event I need to. This approach has worked great for us on our plan / the Cloud version.
Furthermore, all of that process can break down when multiple people across departments are working on the same app and it's less than fully coordinated — a reality in our organization.
Now I find myself having to group a lot of conceptual changes together because I'm paranoid about this pagination bug not allowing easy access to adjacent releases — both before and after the Live version.
I will follow up with our engineering team and share how it's impacting your development flow. Thank you for taking to explain why this issue matters. I'll comment here when I hear back.
Hi everyone! Very excited to let you know that a fix for this regression should be rolling out in the next two weeks. Apologies for any delays or friction this is caused. Thank you all for notifying us of this issue so that we could address it and get a fix out.
), depending on their substance. Sometimes I group little, incidental changes together, other times I'm doing feature work that is exploratory or might present issues if something goes wrong.