Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

App frontends should upgrade automatically to latest minor/patch, not major #222

Open
kernelwhisperer opened this issue Dec 7, 2018 · 3 comments
Labels
bug Something isn't working

Comments

@kernelwhisperer
Copy link
Contributor

If I have an app with the following versions:

 ✔ 2.3.0: 0x230bBCF5688552572B6117a99b7D6E97BF805d8c ipfs:QmaQXfJ6QaA5QiEsY3DqkpKAKKws4NeVDuyEcTL7cdmNX6
 ✔ 2.4.0: 0x230bBCF5688552572B6117a99b7D6E97BF805d8c ipfs:QmaZ2bgYZPuRHkMC8u4bQ5cHx3TLG9beGYpwbnrnL9cbmA
 ✔ 3.0.0: 0x230bBCF5688552572B6117a99b7D6E97BF805d8c ipfs:QmaZ2bgYZPuRHkMC8u4bQ5cHx3TLG9beGYpwbnrnL9cbmA

And I have installed the 2.3.0 version of this app in my DAO, the dapp will be fetching the UI for 3.0.0 because in aragon.js we call getLatestVersionForContract.
Besides being counter-intuitive, couldn't this be dangerous?

@sohkai
Copy link
Contributor

sohkai commented Dec 10, 2018

Besides being counter-intuitive, couldn't this be dangerous?

Yes, it was a choice we made to be pragmatic (to automatically opt users into frontend upgrades) at this point. In the future, aragon/aragon (and hence aragon.js) will provide a way for users to "pin" the frontend version their apps resolve to.

That being said, we may want to adjust this behaviour to only resolve different minor and patch versions based on a major version (e.g. similar to ^ in semver).

@kernelwhisperer kernelwhisperer changed the title App frontend upgrades automatically App frontends should upgrade automatically to latest minor/patch, not major Dec 10, 2018
@kernelwhisperer kernelwhisperer added good first issue an easy issue for a new dev or a bounty bug Something isn't working labels Dec 10, 2018
@luisivan
Copy link
Contributor

Totally agree, and this is a feature we should introduce in the client, so people can just click a button to upgrade to the next version, but it should be an opt-in feature

@sohkai sohkai added blocked and removed good first issue an easy issue for a new dev or a bounty blocked labels May 18, 2019
@sohkai
Copy link
Contributor

sohkai commented May 18, 2019

For the organization as a whole, this is blocked by it being able to hold onto a data blob, but for individual users we could cache some local settings if they want the client to stick to a particular major version of an app's frontend.

@stale stale bot added the abandoned label Nov 14, 2019
@aragon aragon deleted a comment from stale bot Nov 15, 2019
@stale stale bot removed the abandoned label Nov 15, 2019
@stale stale bot added the abandoned label May 13, 2020
@aragon aragon deleted a comment from stale bot May 14, 2020
@stale stale bot removed the abandoned label May 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants