[RFC] Remove releases from the community plan

prakhargupta1 commented 2 years ago

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Summary 💡

Release management is an advanced feature that should not be there in the community version.

When the user clicks Deploy we should:

Directly show the deployed URL
Not show the release workflow
Remove the Releases tab

Context

https://www.notion.so/Toolpad-Pricing-50df8f336b3d4120b8df8a8cef0b7fa9?d=0af1ff513e5b4bdf9bfe3f748d10035d#de48ce63c7c34c149c2aa68a57299e9d

Janpot commented 2 years ago

We would still be doing the exact workflow under the hood. The only real functionality we'd be taking away here is the ability to roll back releases. If we want to advertise some of the features that users are missing in the community plan, wouldn't it be more interesting to keep the releases tab but hide or disable the functionality that is part of the pro plan?

prakhargupta1 commented 2 years ago

@oliviertassinari @gerdadesign What do you think about the solution Jan proposed. We'll show the Releases tab in inactive state. On hover, it will show "Only available in paid plan".

@bytasv We should also mention this in the documentation.

Janpot commented 2 years ago

What do you think about the solution Jan proposed. We'll show the Releases tab in inactive state. On hover, it will show "Only available in paid plan".

I didn't propose that. To clarify my comment: I thought we should leave releases as a core feature. I meant that IF you want to gate a feature around releases, perhaps do it with just the rollback button and rather look for pro features in the direction of: RBAC, access logging, multiple deploy environments, advanced datasources, API access, advanced components,...

Anyway, about this RFC, what's not fully clear to me is if we remove the releases feature, what does the "deploy" button do exactly? Or do we remove the deploy button as well?

prakhargupta1 commented 2 years ago

Anyway, about this RFC, what's not fully clear to me is if we remove the releases feature, what does the "deploy" button do exactly? Or do we remove the deploy button as well?

It means only the latest release will go to production and there will not be any 'release management' as such.

I think release management is something that a pro user would do. So it makes sense to put it in the paid plan.

bytasv commented 2 years ago

I'm trying to think of a personal use-case when I would be interested to choose past version and redeploy that 🤔 (I mean regular flows, nothing too fancy) As long as I have an option to "rollback" even if didn't have an option to choose different versions I think I would be covered for many different cases. So I was thinking that if we are looking into putting this feature behind paid plan then maybe instead "free" Toolpad version by default should only allow to have "live" version of the app available without any deployments (think of what preview does right now). This way if you wanna use Toolpad for something more advanced and you don't wanna accidentally break what you built in the past maybe you would more inclined to pay for ability to "release"

Janpot commented 2 years ago

So I was thinking that if we are looking into putting this feature behind paid plan then maybe instead "free" Toolpad version by default should only allow to have "live" version of the app available without any deployments (think of what preview does right now).

exactly what I wanted to arrive at 🙂: if you want to you could take the whole "deployments" feature away, and then "preview" would become the production version.

I'd still keep releases in the CE version though, it's completely impossible to work on the app while at the same time have someone else use your application. Look at it as "save points". I mean, there's limiting features for CE, but this feels more like deliberately crippling the usability to me. CE edition doesn't have to mean "demo edition", I think it should still have good enough basic functionality for small companies, independent devs, open source projects,...

bytasv commented 2 years ago

IMO even the "always-live" version is useable, it's not great UX ofc, but I guess at the end of the day it all boils down to what features for we wanna charge our paid users. I.e. recently I used an app which allowed editing picture, it had a feature that I was able to use - cut out background, but unless I paid for premium version I could not save that specific change :) In this case it would be like - you can use and publish and share with others, but have in mind that free version has this limitation - if you work on it you can break something for whoever is using it right now 🤷

prakhargupta1 commented 2 years ago

An app could still be usable. Just that the developer will have to convey to the end user that "I am updating the app, I'll let you know once I make the changes. Till then don't use it."

Janpot commented 2 years ago

An app could still be usable. Just that the developer will have to convey to the end user that "I am updating the app, I'll let you know once I make the changes. Till then don't use it."

What if the developer halfway changes their mind? Or runs into a roadblock? Do we tell them they have to backup their database in between making changes, so that they can restore?

...you can use and publish and share with others...

Exactly, some features were unavailable, but you could still publish. Pretty dark pattern btw, to have people make changes only for them to find out afterwards that they can't save anymore.

oliviertassinari commented 2 years ago

I'm personally OK with https://github.com/mui/mui-toolpad/issues/795#issuecomment-1227048249. It's not clear to me if the feature should be paid, or even exists at all if we provide Git sync. Hiding this feature can reduce the surface area of features that we need to do well, hence overall help.

So far, I have found it more painful to have to describe and version my releases, than it brought value to the mini-app that I have created. I mean, having to write commit messages hasn't paid off so far for me with the Toolpad apps that I created. The closest feature to version history that I have felt the need for with Toolpad is to answer:

Who changed this app in the past? It looks different now. I might ask him why so I don't break his work.

Which I think means that in https://master--toolpad.mui.com/_toolpad/app/cl4hla83p01949xoizo5uxf2a/releases. I need to see the author.

Note that #658 is a versioning workaround. Figma limits it to 30 days, but you can also duplicate your work, to save previous versions 🙃

I think that this can work as well.

bytasv commented 2 years ago

What if the developer halfway changes their mind? Or runs into a roadblock? Do we tell them they have to backup their database in between making changes, so that they can restore?

@Janpot IMO - it really depends how we want to price things - if we think that this should be paid feature, then answer would be yes - if you don't wanna loose or mess things up you should back up app (but we don't have that feature either). So it's just a perk that you would get if you PAID 🤷

So far, I have found it more painful to have to describe and version my releases, than it brought value to the mini-app that I have created. I mean, having to write commit messages hasn't paid off so far for me with the Toolpad apps that I created. The closest feature to version history that I have felt the need for with Toolpad is to answer:

@oliviertassinari I personally think that if we had "versioned" deployments it could be a little bit simpler. It should be "one click" to deploy new version - current date would be used as a version ID. After that - you are live. The only time you would want to use previous version is when you want to rollback, so technically it could even act as "save project" feature that allows you to restore to previous versions 🤷

Janpot commented 2 years ago

it really depends how we want to price things

That should definitely be a big factor, but Toolpad is also an open source project, which means that we also try to build a relationship with a community of volunteers. IMO we have a responsibility in this relation to provide a core that is usable enough and not merely a demo version of what could be if you paid. Remember that the C in CE stands for "community".

App lifecycle is an inherent part of what Toolpad tries to be and therefore I believe it make sense to at least support a basic version of it in the CE.

bharatkashyap commented 2 years ago

"free" Toolpad version by default should only allow to have "live" version of the app available without any deployments (think of what preview does right now). This way if you wanna use Toolpad for something more advanced and you don't wanna accidentally break what you built in the past maybe you would more inclined to pay for ability to "release"

To me personally, this captures the best middle ground between not breaking the contract of a community project and trying to capture a percentage of the value delivered to a user who is able to pay.

We could even stretch and say that the real value is in showing "logs" related to releases and not merely create multiple releasable instances, i.e. in being able to get an answer to this question:

Who changed this app in the past? What change did they make?

but allowing releases but putting version history behind a paywall hat seems to venture into the "include just enough functionality but hide the rest to get users to pay" territory.

So, I think we can keep releases out of the community plan and have the current "Preview" be the "deployed" version of the app. We could include a "Releases" section for better discoverability of a paid feature.

oliviertassinari commented 2 years ago

it really depends how we want to price things

I have left the same feedback to @prakhargupta1. We will first get more clarity on what the goal of each plan is. Once we have this, answering this RFC should be a lot easier.

As an extra benchmark: pipedream.com ~doesn't have versioning~. So far, I have felt no pain about this when using the tool (I maintain 6 workflows so far). I'm using two release states: one is the working environment and the second one is the deployed environment. These two seemed enough for the simple workflows that I'm building.

I think that for more advanced workflows, I would want to drop pipedream and move to something more pro-code, and likely on git. We might be able to draw the same parallels for Toolpad: it's for simple apps, if you have used cases that are too complex, drop it, go pro-code, and use MUI Core + MUI X.

In the long-term, the whole point of our work on Toolpad is to move the point where you would want to drop Toolpad: as far as possible, so I imagine we will eventually need versioning. But in the beginning, we might want to focus on nailing the simple use cases.

Janpot commented 2 years ago

pipedream.com doesn't have versioning

Their deployments feature looks pretty close to me to how we do releases with Toolpad.

Main differences:

pipedream deployments are snapshots of the application, the last created snapshot is the production version, rolling back means creating a new snapshot based on the one you want to rollback to.
in Toolpad we also work with snapshots, and together with that a pointer that points to the production snapshot, rolling back in Toolpad means changing the pointer to the snapshot you want to rollback to.

Janpot commented 2 years ago

I proposed an alternative as a separate RFC (https://github.com/mui/mui-toolpad/issues/868), but can add it as a comment here instead if that makes more sense?

oliviertassinari commented 2 years ago

Their deployments feature looks pretty close

@Janpot One thing that I have found frustrating with how they have implemented their UX: When making changes that you don't like, the only way to trash them is to deploy an older version, and then redeploy the current version.

Janpot commented 2 years ago

One thing that I have found frustrating with how they have implemented their UX: When making changes that you don't like, the only way to trash them is to deploy an older version, and then redeploy the current version.

Just for my understanding what is the pain here exactly, a scenario:

a user deploys their application
makes some changes in the editor (we could call this "staging")
realizes it's not what they intended to do and want to "reset" the editor to the last deployed state

Is that what you mean, a git reset --hard but for toolpad?

(alternatively, for 3. reset the editor state back to any other past deployment.)

One way we could go about this is to add an option to each deployment like "reset editor to this snapshot" or something, with a big warning sign.

mui / toolpad