A Monthly Pause in New Feature Additions to Create Stable Wappler Versions

Feature Request
#1

Well this is not a feature request, it is a Wappler Release Strategy request.

As Patrick replied to me last week, many new features are being added rapidly and that is clearly increasing the number of bugs in the product.

Two key features had bugs that completely broke my app in the last few weeks: keyed objects and custom database queries.

I no longer have any idea which version of Wappler is stable enough to work with all the features I need.

This request is for the Wappler team to spend a few weeks releasing new features, and then a week primarily focussed on bug fixes. At the end of this process, the stable release is clearly identified so those of us who need stability can stay with that release until a new stable release comes out (maybe a month later).

This feels really important for me to:

  1. Be able to trust Wappler.
  2. Support the quality of the product I need for my user base.
  3. Ensure the productivity benefits I gain from using Wappler are not lost in chasing bugs in the product.

Best wishes,
Antony.

#2

Got my vote Anthony.

Iā€™d also happily put myself forward as a BETA tester if releases are separated between production and betas @George @Teodor @patrick

#3

the experimental feature is already in use. There is no software that does not contain any errors. I think only one page where old versions can be downloaded is enough. Because versioning is already in use.

Also, there are sometimes serious changes between versions. I am also really against the use of beta testers. I have been here since the forum first opened (even before. I am a very old user) ā€¦ a user who has just started using wappler can find more bugs than users who have used wappler for a long time. Also how to decide how good beta testers will be. The user who is good today may be bad tomorrow. This approach is not good at all.

2 Likes
#4

I think this along with the use of git, is the fastest way to get what we need, which in my case is a) rapid development of the editor, along with b) the ability to roll-back when things break.

Workflow would be:

See an update.
Decide when to apply the update (maybe wait a few days if not interested in the risk.)
Commit with git to protect code.
Apply update.

If things are not to your liking:
Download the version you want.
Install.
Roll git back to pre-update commit.

There is always a cost to asking developers for more stability. They will naturally slow down, thus negating one of Wapplerā€™s advantages as a small businessā€“speed, flexibility and EMBRACING risk rather than running away from it. Leave risk avoidance to the big guysā€“let them stifle innovation. Wappler is, and will continue to be, in competition with other providers, and the product is just not ready for the burden of improved stabilityā€¦especially given that the wappler product updates in no way touch production unless the developer so chooses.

The team has already implemented the experimental process for major changes, which further gives us the ability to choose our risk tolerance.

Even the process of deciding that a release is stable introduces more process, testing and complexity. Iā€™m also assuming (complete wild guess) that rolling back Wappler is not as simple as one might think since the resulting code gets modified. The version you roll back to doesnā€™t know what the next version did to the project code.

THREE GUYSā€¦just THREE. I for one applaud and strive for the same in my business endeavors. Skip all the management headaches and just get things done.

OF COURSE, we need a way to protect our own needs as well, to which stability is more important. Git is the standard. If Wappler can add the ability to download versions, I think weā€™ll have a winning solution.

ā€“Ken

5 Likes
#5

I think this would be a good idea too. One obvious solution would be to save the previous installer before upgrading. I always to do this - but I donā€™t think Iā€™ve ever decided to revert to an older version.

In case itā€™s useful, the Windows installer will be here:
C:\Users\username\AppData\Local\Wappler\temp\Wappler-win64-2.5.x.exe
ā€¦ and the Mac version:
/Users/username/Library/Application Support/Wappler/temp/Wappler-Mac-2.5.x.dmg
(at least on my computers).

1 Like
#6

I actually prefer the weekly updates, itā€™s something to look forward to and gives the feeling of progress. This feeling of progress might be just a feeling though.

Usually bugs are fixed fast enough anyways, but I can imagine that itā€™s an issue for some if anything breaks in the mean time.

1 Like
#7

I also prefer weekly updates. But I do understand the concerns.

All new features could go into experimental branch until they graduate. And the stable branch could maybe only receive bug fixes for graduated features.

In the meantime remember to use GIT and that you can always ask them for old version.

However, having all versions publicly available is probably a bad idea. Because the team would have serious issues to track bugs for each version and the risk of adding more regression would be higher.

5 Likes
#8

Even with the odd bug in Wappler which can be frustrating, I think you may forget program like Dreamweaver still had more bugs than Wappler ever has. Lets face it if it a big issue they release a fix very quickly, little bugs normally get sorted out within the next update. I say leave it as it is, Wappler is becoming more and more powerful on every update.
Keep up the good work @George @Patrick @Teodor

2 Likes
#9

Hey everyoneā€¦

Thanks for contributing to a great debateā€¦ it is wonderful to so quickly see something that builds up in one direction in your own mind from so many other perspectives.

Iā€™m certainly not asking for the rapid release of new features to be curtailedā€¦ far from it, I get excited on Thursdays like the rest of you!

I would just appreciate a Thursday on a regular basis - maybe once a month - when the release doesnā€™t contain so many new features, and is more focussed on stability. I am sure that wouldnā€™t reduce the wonderful innovation that the team brings - and I would guess that in the background during a lot of that week they would be working away on some wonderful new features for the week after. But for those of us where stability really matters, knowing there will be an upcoming ā€œmonthly stability releaseā€ would feel safe and re-assuring.

I look forward to the teamā€™s perspectives during next week!

Best wishes,
Antony.

2 Likes
#10

@George, Iā€™d appreciate your views on this request! :slight_smile:

#11

Well we donā€™t plan to slow down the new features any time soon, but we are making various improvements to make the process much more save and bug free.

But indeed with every change comes danger that things can break. But this is just a risk to take in sake of progress.

We already cover a lot of testing ground but the real test is when you guys get the hands on it. It is unfortunate that a bug is then discovered but then we know it and can fix it immediately. And if it is really crucial, we release a fix immediately.

Of course as our core stabilizes there wonā€™t be any bugs with such impact left, so everything will be much more safe.

We are also working on much more extended internal procedures for automated testing so that no bugs slip in a final release but it is a lengthy process to get this fully implemented.

Another thing we work on is to offer much more control on site updates when the components are updated. So you can choose what to update and what to leave alone.

Lastly we also want to improve the deployment process so you can only deploy full sites after testing them first and after being deployed they can only be changed by full redeploy - so you want be breaking easily existing working sites.

10 Likes
#12

That would be great.

Presumably this will only be an option, but I wonder if site updates are made like this generally - all or nothing. Iā€™m sure there are situations when this applies, but not usually (I would have thought).

#13

A thinking persons resolve to the issue! All in safe hands.

:smiley:

#14

Thanks for your update on the strategy here @George! It sounds like you have some great plans.

I need to keep my life simple regarding site updates, so I would presonally still prefer the monthly ā€œStability Releasesā€ thoughā€¦ :slight_smile:

Best wishes,
Antony.

#15

@Antony - how about you download the latest version as itā€™s released but ā€˜shelve itā€™ and only install it the following week when you then download the next one. This way any major issues (there havenā€™t been many) will be spotted and fixed before you install it. Youā€™ll just be one week behind everyone else.

I love Thursday afternoons and actually refresh this forum frequently looking out for the next version and seeing what it holds so any sign of that reducing would upset me a little.

2 Likes
#16

I confess, unless I am waiting for a specific bug fix, I often defer updating a while and check bug reports just in case something which would be catastrophic to me arises. But if everyone did that the logic fails!

I also only update one system initially

2 Likes
#17

It is coming into the forum and seeing a line of bug reports like this that makes me nervous and ask for monthly pauses in new features!

I just want a release once a month I feel I can reply on!

Screenshot_20200306-143318_Chrome
Screenshot_20200306-143318_Chrome1080Ɨ1920 341 KB

#18

@Antony
Some of these ā€œbug reportsā€ are user errors and some of them are not even related to the latest updatesā€¦
Anyway - there is no bug free software and as George explained above:

Update once a month is not an option for us.

#19

@Teodor, The request is for new features for 3 weeks then mainly bug fixes for one week, to create one version each month which is more stableā€¦

#20

George already explained our vision and plans about this in his comment and there is nothing more to add to it.