Project-Wappler version control for Wappler build updates

Feature Request
#21

But the UI changes to match framework(AC and SC) changes.

An example.

You develop a project in 3.0 and don’t touch that until today because a client asked for something.

From 3.0 to 4.0 around 50 updates have been delivered. Those 50 updates sync SC, AC with the UI. This means that the UI from 4.0 matches the functionality of the current SC and AC.

Now you want to open an old project to make changes in a UI that doesn’t match the version of AC and SC that you want to maintain.

Let’s say you want to add a new condition to a server connect flow. When you add a condition the UI might append some data to the file that is not supported by the old SC framework and literally break your app.

1 Like
#22

That would be quite a different matter. The example I gave was:

I’m sure people appreciate that if you want to use the latest features in the Wappler framework or the latest version of Bootstrap etc, you will need to upgrade the site you’re working on.

I think the main point of this thread is that the developer should have a choice - do they want the site to stay essentiallly as it or do they want to upgrade? The former may be perfectly sufficient for most purposes (the telephone number or other minor changes, or changes which might involve a little manual coding). The latter may be more appropriate for continued development of the site - it should not be mandatory.

There have been a great many threads where upgrading Wappler has broken something. I think the suggestion proposed in this FR will help prevent this happening, or at least prevent unwelcome surprises. It will give the developer more control and perhaps increase users’ confidence in Wappler generally.

Can I use Wappler without Bootstrap?
#23

For simple changes why not use a simple text editor?

#24

BTW, if you use GIT you can discard all changes Wappler does with a new version. It’s literally a one command/click simple thing.

1 Like
#25

I was just going to say the same :smiley:

2 Likes
#26

Of course this is an option, and is often the simplest solution. However, it’s very convenient to have a central place where you can easily access all of your projects, and edit any files - ideally without the fear of unexpected consequences resuting from simply by opening a file.

I think this is the greatest weakness in Wappler and has been from the beginning. It will continue to be a serious problem until it’s addressed in some way - eg following @raymantle’s suggestion at the beginning of this thread. I think automatically updating/replacing files without any warning is always going to cause problems - for an experienced developer, an inconvenience; for others possibly catastrophic.

#27

It is evident from the large number of posts on the matter that Git is not a solution - or hasn’t been so far. Perhaps it could be a solution, but it would be necessary to provide some warning to the unsuspecting user - ‘before upgrading to the latest version, please ensure you are using and understand Git - otherwise by simply opening a file in this project, you might render your site unusable’.

A warning with options suggested in this FR would be much better.

#28

That is correct.
But as @TomD has noted, its not a solution. Wappler does not force Git, so options to manage updates/version should be in-line with Wappler’s way of doing things - hence I suggested the prompt.
If Wappler would require all projects to use Git, then there would be no need for a special upgrade prompt & it could be integrated in another way.

Even right now, the updates are a hit and miss. I updated to 4.2.2 recently & in 4 different NodeJS projects, I saw many different files updating - even in lib folder. For dmxAppConnect JS stuff, I understand only components in use are updated but the internal lib files should be common across all projects of same server model. I know this happenned thanks to Git, but many don’t use it, so they wouldn’t even know they didn’t get the complete update.

There is definitely a need for change in the way versioning and updates are handled right now. @George has explained its not that easy - but i’m sure they can come up with something better probably starting with a simple YES/NO prompts with suitable warnings.

1 Like
#29

Needless to say that I understand the problem that is being raised in this FR.

The only problem I see is with the approaches that are being suggested. IMO they change the core of Wappler’s releases while opening the doors to additional workload that doesn’t justify the change because there is already a great tool out there to cover this called GIT.

Maybe, the right solution is to start enforcing GIT locally. So for each new project you create a local GIT repository will be created and you will need to learn a bit of GIT. It is good practice and people should stop fearing it.

Then, the team just needs to think of a good GIT workflow that makes sense in Wappler’s context so when there is an update of files it automatically performs an action in the GIT workflow to allow undoing the changes if needed.

If the user wants to undo only Wappler’s update he can click a button and Wappler will perform another set of commands in the GIT workflow they decide to undo the update changes while warning them before hand that the UI might not work correctly and might break their app if they make changes.

And still they would need to tackle how they will identify when someone opens a bug post in the forum where he complains wappler broke their app while having an old framework version and a new UI version.

There will be thousands of combinations of framework versions and UI versions that will become a nightmare for them to identify what is a real issue and what is the result mismatched versions.

All in all I have my doubts that this FR will improve things. Not because it is not a valid concern or this problem doesn’t exist, but because I think it is a FR that has its roots in user bad practice.

2 Likes
#30

Starting where you ended your point - bad user practice - is not limited to the users of the app, but also applies to the app itself. Git tools did not exist in Wappler until some time ago.

There are numerous users who adopted Wappler as their go-to-tool and changed their workflow as per the app. Becuase Wappler did not have any built-in Git tools for a long time, it wasn’t required to build with Wappler. It certainly would have been a visionary move to enforce Git when it was added. :sweat_smile:

But coming back to the problem in present. Git is like a minimum requirement for a dev - and I think that because I made the difficult transition.
For a new guy, its expected to be a known thing, but for seasoned devs it is a big task - specially when they are so frightened of it.

Wappler certainly has the guts to enforce Git but it has to do so in baby steps.

I don’t see this as big issue at all. Because there will be versioning built in to the project, the UI could just identify and show a constant warning of an incompatibility between Wappler IDE version and version of project being opened.
And on community, the team could just discard bug reports that are due to incompatible versions. Might make their bug reporting and resolving process more robust and transparent in the process.

I have no doubts that if discussed and done right, this FR will definitely improve things. :slight_smile:

1 Like
#31

Indeed. I know they will figure something out. I just hope it’s based on GIT as it’s the right tool to do it.

Regarding forum support I am pretty sure it’s going to create trouble but that is for them to decide. People will not bear not being able to open a forum topic if Wappler breaks their app. It doesn’t matter how many warning you show them.

#32

Several suggestions have been made in this thread, and I agree some could cause support issues. However, I’m also pretty sure that some would reduce support issues.

If a Wappler user returns to a project after some months or even years and makes a simple change (eg the telephone number example), as it stands, making such a change could break that project. This would likely lead to support issues.

If a message is displayed offering an option not to update any files automatically, nothing would break and there would be no support issues.

#33

Unless they don’t know what they are doing and it’s more than a telephone change :wink:

It all seems practical and easy to understand as we are involved in this discussion. But for the rest of users that are not active in the forum(the great majority I guess) it will just mean to them that Wappler broke their app and they have no clue why.

And that will produce support requests where the team will have to chase people to get information about what UI, SC and AC versions they were using besides what they actually did.

People shouldn’t leave sites unattended for months/years. It’s bad practice and the source of this FR. Developers should update their sites frequently, among other things, for security concerns.

So I am afraid I can’t back a FR based on a horrible practice :slight_smile: It’s against my dev principles. Not that it matters too much as it already has 19 votes although some are duplicated.

1 Like
#34

Hi all,

I didn’t expect this much debate on this FR however, the more the better so that we can suggest the best possible solution to George and Teodor and see what they can do.

I would just like to clear up some points.

  1. The main focus of the FR is to highlight a project that when opened in a newer version of Wappler that had a fundamental change, I would at the very minimum be notified of what SA files of which need to be updated with a change in order for my project not to break.

    e.g. when the reference to the schema changed ** tblAudit\n** changed to ** “dbo.tblAudit”\n**

    This change made it that the SA didn’t display in Wappler correctly and I had to delete it and redo it.

    I think there were also other changes in the JSON that affected this also.

  1. I agree that while it may be bad practice not to keep updating a project everything there’s an update to Wappler SC, it’s a valid business decision not to, and I’m sure there are many business owners here who could not take on the cost of updating every project every time there’s been an update to Wappler.

    If I develop a website for a customer, I don’t know if they will ever want changes made again, and to consume the cost of updating every project on an ongoing basis is not feasible on the off chance that the customer will look for updates to be made.

  1. As @sid said,

    When an older project is opened on a newer Wappler - a transition alert should show.
    This would include a list of all BREAKING CHANGES in all the versions since the older one.

    This would at the very least, tell me what changes I need to make to existing projects in order to get a project up to date without searching through the community post to identify possible changes that I will need to implement.

In relation to using a text editor for minor changes, yes I’m sure that for many this is a quick workaround, but realistically, why should I need to resort to using another app for these changes when I am paying for a powerful app like Wappler.

Ray.

#35

Indeed it’s an interesting debate.

This information is provided by GIT if you use it. It tracks all changes and there is a button/command to undo it if you want to. Besides this the usage of GIT is considered a best practice and it has dozens of thingies that will improve the DX(Developer eXperience).

If there is a tool out there that does this automatically and isn’t prone to errors why would we want to add a human process that costs time/money to the team and is prone to human error. They already have enough on their plates.

The way I would handle this is let the customer know(in the contract) that if they don’t want to keep updated that is OK but if and when they decide to do a minor change they will have to pay the change plus the time needed to update the application. While it might be a business decision not to update, us developers have a reputation to maintain and some ethics/standards to stick to.

Extracted from https://www.computer.org/education/code-of-ethics

Software engineers will…

1.01. Accept full responsibility for their own work.

1.03. Approve software only if they have a well-founded belief that it is safe…

3.14. Maintain the integrity of data, being sensitive to outdated or flawed occurrences.

8.02. Improve their ability to create safe, reliable, and useful quality software at reasonable cost and within a reasonable time.

Because we don’t want it to increase in price. What if they decide that this FR is worth implementing and they decide to hire someone else just for this and pass the cost to us as it would be expected.

You guys are requesting additional time to be invested by the team on a recurring basis(every week) for something that is entirely your responsibility, keeping the app and websites updated. No thanks. Still a FR based on bad practice.

#36

Maybe I’m missing something about GIT. GIT will not help me identify a SA file that needs updating because of an update to SC by the Wappler team.

Remember, I’m talking about a change from the Wappler team that requires me to modify a SA file in order for it to display and work correctly.

#37

Not directly, but it will notify you of all the changes that were made to the framework which should allow you to pinpoint the error better and request support in the forum.

If I see that the SC core db file was changed and I’m getting an error on the database level I can start digging there. I would then review all the public and weekly patch notes that have been published since I last updated that website looking for changes to DB logic.

#38

OK, so that’s where we differ.

I don’t want to “review all the public and weekly patch notes that have been published since I last updated that website” when there could have been a number of Wappler updates that I would possibly need to identify and weed out.

Maybe the guys can come up with a solution that works for both.

#39

Maybe additional information in the changelog might help here. I gave a real example above where GIT wouldn’t solve it:

However, I completely relate to @raymantle about opening a project that might not have been touched for a year or two, making changes which could be very minor but that then break things because of a Wappler update during that period. Just an alert that says ‘action x has now become action y’ and show this when such a scenario is actually affecting the project.

1 Like
#40

I think this approach would work well - assuming you don’t actually want any customers.

Minor updates, such as changes to static text and graphics or modifications to spacing or colours etc. should really not require an update to the application - to new versions of the underlying database or js and css frameworks. If I were going to hire a developer and these were their terms, I would look elsewhere. If the explanation for this approach was due to the software used by the developer, I would think this a very poor justification.

I would certainly agree with @raymantle. I would also say such business owners would be wise to take such an approach.

1 Like