I've been using Wappler since its inception and use it for small, static projects. So I'm not inclined to update Wappler to 7.2.0, even though it prompts me to do so every time I start it. Could this be a problem in the future?
Which version are you currently on?
For static only sites there likely isn’t a lot of difference aside from the UI changes. Having said that, in my opinion, it is always best to keep up to date. Updates happen for a reason.
1 Like
For static projects it doesn't add lot of extras except that it is bundled with the latest versions of the App Connect components. I would update Wappler after you finished your project or when you just started a new one to prevent problems with incompatible components just before you are about to release your project. It is always good to have the most up-to-date version.
You can always check What's New in Wappler 7 and decide for your self.
I suppose the converse question is "Why would you not?"
if later versions are better (which they are) what is the benefit is not upgrading?
It feels like driving a truck to transport a matchbox, but I've decided to take the plunge. 
Personally, I don’t have the courage. I use version 6.8.0. I’ll consider updating when they announce the last stable release before the first Beta of version 8.
1 Like
7 is by far the most stable platform yet, 6 final still had bugs that have been fixed in 7.
2 Likes
In the past, I used to update immediately after the update notification. However, once I understood the development team’s priorities, I began reducing the frequency of updates.
My dream would be a major version (7 to 8) with a total of 0 new features, but with all existing features fully polished. But from what I’ve seen, that’s not going to happen.
The philosophy of the environment isn’t productivity-oriented. Time is wasted fighting against a terrible usability interface, time is wasted trying to figure out whether something doesn’t work because of logic errors or because of one of the tool’s millions of bugs, time is wasted trying to understand how features work and searching for community solutions due to the lack of documentation, time is wasted doing QA work and reporting bugs on the forum. Which is confusing, since it’s the exact opposite of the premise of low-code development. I feel very close to traditional coding.
Slowing down the update pace seemed like a viable way to reduce the number of variables and the impact of all these problems. I still have to deal with the same bugs that carry over from one generation to the next, but at least they’re familiar, and I already know the workarounds. I miss out on the latest new features, but at least I make my productivity a known variable.
Maybe version 7 really has improved, but I’ve wasted so much time in the past struggling with issues in the tool that I honestly feel zero excitement to try it. Maybe I’ll install it on my laptop to take a look. Someday.
3 Likes
To be fair, most bugs now seem to result from users trying to do things that were not thought of at design time or never intended rather than bugs in the implementation.
And yet, over the past 4 years you have 6 bugs topics created, 5 of which have been fixed and 1 was not an actual bug. We can't fix a bug (or to be specific "millions of bugs") you know about and we have no idea it exists 
I’ve been updating as soon as each version is released. I’ve been doing this since v1. I think I’ve only hit a problem a couple of times in all these years and I still genuinely look forward to Thursday afternoons when the next version will be released.
Any moment now….. 
2 Likes
I am dreaiming of a light version or a version where you can select the tools you use and pay accordingly.
The basic version of Wappler is a "light" edition, perfect for small static websites and priced accordingly (99 eur/year for the plan you're using), which is about 8.25 eur/month.
Theodor, bug reporting is extremely time-consuming work for something that isn’t compensated. Especially in my case, since I’m on a long project protected by an NDA and it requires me to create interfaces and dummy data to publicly replicate each problem. I’ve resorted to just dealing with the error and moving on.
Just now, about 3 minutes ago, I had to change the data bind from ItemsToProcess.data.where(line_item_id, line_item_id, '==') to ItemsToProcess.data, because the Flow Editor refuses to show the fields for use in child elements when I keep the .where(line_item_id, line_item_id, '==') in the data binding. After I finish working with the child elements, I go back to the upper data bind and put the .where(line_item_id, line_item_id, '==') back. Just to give you a recent example (and honestly, this is one of the most recurring ones).
1 Like
Not sure i understand what the issue you are having is, but it will be helpful if you post a proper bug report explaining the issue in details.
Creating a bug report takes a minute at most.
Reporting a bug isn’t always as easy as you say. And what if the developer can’t share screens from their project? It’s necessary to create a sample interface, data structures, dummy data, take screenshots, script the error reproduction, review the text (especially if English isn’t the native language). And you also have to be prepared to return to the thread to provide more details.
I can make the proper report in the appropriate forum section… and then send you the invoice! However, if I’m not updating the tool because of the concerns I’ve already mentioned, and considering that most developers have probably already moved on to version 7, I question the impact of a possible fix.
This defensive narrative (with an emoji to soften the insinuation) that associates forum participation with the truth of a statement about bugs is mistaken, and I’ve seen you use it before. In a way, it shifts the responsibility onto me for not contributing to the tool’s success. Instead, how about thinking of a properly paid QA team? In my project, we have one—and it works very well…
3 Likes