Hey, working through the code of the Review Extens...
# general
f
Hey, working through the code of the Review Extension we found a whole lot of stuff that seems very old to me. Could you people take a look if that’s something that shouldn‘t be kept? There are endpoints to review a Review on a 5 Point scale (no, no pun) and I want to have a feeling anybody cares about that or if we maybe a Revision dropping some stuff should be considered. https://github.com/solidusio-contrib/solidus_reviews/issues/63#issuecomment-2535697618
@mamhoff I saw you worked extensively on reviews, can you tell me what kind of features you are using?
m
I don't think it matters what my clients use. In general, we go out of our way to keep our changes backwards-compatible, so removing features is hard. This might explain the reluctance you're experiencing for adding them in the first place. Solidus (and the extension ecosystem) is used by many stores making quite a decent amount of revenue. We don't want to leave older stores behind, so we need to provide migration paths whenever we remove features for stores that do use them. Similar with the legacy frontend: Yeah, the thing itself is out of support, but we know for a fact people are still using it, so we're not yanking the gem or deleting the repo, and behave nicely throughout the ecosystem for people still using it.
f
ok, do you know why the old frontend found so much adoption but the new one didn't
🤷 1
Are they using the old frontend with a current solidus Version or do they feature freeze?
m
I can only tell you what the constraints are for getting stuff merged. The software is free to download for anyone, and it doesn't contain any "phone home" feature that would tell us what parts are used, by how many people.
This makes change difficult. I would personally often prefer that not to be the case, but I do appreciate the stability of the ecosystem.
👍🏻 1
f
I'd vote in favor at that point of making a separate release for starter-frontends to clearly separate.
Man, you are reading everything
🍿 1
it feels to me intuitive than say keeping both front-ends alive, at that point deprecating old front-ends does not make sense
c
ok, do you know why the old frontend found so much adoption but the new one didn't
In my experience all new stores spun up will use the new frontend, but stores that were created before that existed are less likely to do the work to migrate and often have pulled/overriden most of the legacy frontend they are using and manage that in their app anyways.
f
do they migrate to newer versions or stay on 3.x or maybe even 2.x?
c
The one store I worked on that was using the legacy frontend, was on 3.2
t
Since the legacy frontend and the starter frontend are fundamentally different (one is a Gem you mount into your Rails app, while the other is a generator for a Rails app), I have a hard time imagining someone will ever migrate. It makes more sense to import all the code from the legacy frontend into the host app and keep maintaining it. Most stores I know built a completely dedicated frontend application (mostly written in JS tools).