Project-Wappler version control for Wappler build updates

Feature Request
#1

Hi,

After building a few projects on previous versions of Wappler, I have come across issues with SA’s that no longer work due to major changes in Wappler.

Is it possible that when we build a project in Wappler, the Wappler version is written in a version control file, then when I open the project in a newer version of Wappler, Wappler will update SA’s with the correct updates applied for each version between the project build version of Wappler and the version currently running?

Ie, Build project in version 3.1.1 and just installed version 4.2.2.
When I open the project it should apply any updates that have been made to SA files from version 3.1.1 up to version 4.2.2

So if in one of the build versions there was a change to how the schema is referenced in queries, this update would be applied to the SA file.

Maybe this isn’t a problem for most, but I have projects that I may have to look at 1 or 2 years later and I would hate to have to manually rebuild SA files in order to run correctly on the latest version of Wappler.

Thanks
Ray.

Wappler 5.6.0 Released
2021: The Year in Review
Updating Project Files
Wappler 4.4.1 Released
#2

Having a version control on app level would be great.
But I would like to propose handling of updates a bit differently:

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.
Options on alert could be “Update with Fixes” & “Update w/o Fixes”.
In first option, Wappler could modify code to handle the breaking changes automatically - if feasible. For eg: Adding schema to existing SA JSON, which is your case.
For others cases which are not feasible, user will at least know what is going to break.
Second option would act just like it does right now - updates Wappler files, does not change any other code.

Along with this, I would prefer a more robust in-app version history with clearly marked breaking changes - for cases when Wappler cannot apply fixes for those breaking changes automatically, user can at least have something to refer to instead of going to 10 different posts in community.

The team does not do breaking changes usually, but I know of at least two instances (auto-validation & ASP query schema) where they did it unintentionally, and there are now many posts asking about these.

1 Like
#3

@sid You put it more clearly than I did when it comes to updating options and that makes more sense.

#4

This is a good request.

To add another scenario I’ve found when opening a project which was last worked on about 2 years ago was the change to globals. Every SC script had the connection and security actions in it but they are now redundant. Having them there didn’t actually break anything but the code for things like {{identity}} changed from {{security1.identity}} so I did hit some issues. When I spotted something broke, I just removed the old actions and updated anything that used those variables but it would be great for this to happen automatically.

#5

@sitestreet Don’t forget to vote pls.

#6

I already did :slight_smile:

1 Like
#7

I think a third option would be useful: “Don’t update anything”. If I open a file in a text editor, I would typically only want/expect that file to be changed. I appreciate that Wappler is not simply a text editor but it would be great if it could, if required, behave like one in this respect. Dreamweaver is not simply a text editor either, but I’ve never know it cause unexpected problems simply by editing an old file.

I still have sites created many years ago, some over 10 years, which have been little altered since they were developed, apart from the odd maintenance updates etc. They are of course due for an update, but the sites may function as the owners want and they may be reluctant to have a new site developed yet.

I don’t use Dreamweaver anymore so I’ve moved these sites to Wappler, where I can make simple changes without causing any problems. Strangely, it’s the sites I created in Wappler a year or two ago which I’m more concerned about breaking - eg by simply opening a file to edit some text for example. Hence the suggestion for a third option. From my point of view, this would be the most useful option, and will become more so as time goes by.

#8

Hi Tom,

I believe that’s what Sid is suggesting. “Update w/o Fixes” It’s update Wappler application without applying any fixes/changes to your project files but still show somewhere what fixes would be required if you were to save a file in the new wappler build in order for you to identify what would break.

Ray.

#9

I understood from @sid’s suggestion that updates would be made - eg to files in the dmxConnectLib and dmxAppConnect folders - but no fixes to the files created in the project (by us) would be made:

I would prefer to have the option of not having Wappler files updated. (I mean in the opened project. Obviously Wappler application files would be updated when Wappler updates were made.)

#10

I actually thought of that, but did not include it. I am not entirely sure how this part of Wappler works, because sometimes, it breaks for some users even now.
In such cases, team suggests to delete the dmx folder and it gets created automatically.

Another reason why I did not include this in the request is Git.
People need to use Git to track changes and discard or not commit when not ready to push those updates to production.

I understand many people are still using shared hosting or FTP deployment, which is perfectly fine. Just becuase we are moving towards VPS & NodeJS and all the newer shinier things, does not mean previous workflows were bad. They are just a bit out-dated. But one thing all workflows can upgrade to is Git.

I assume having the third option will not really cause any issues, but think of not adding it as an annoying Applie-like weird descision - driving people to something that is not necessary but a little better - Git.

I would rather not have that. VSCode has similar UX - open folder/project/just-files - and I don’t consider it a “serious” IDE for that reason. Just my perspective at this point, I guess. :sweat_smile:

#11

This is why I would like an option to avoid the possibility of anything breaking. I would like the option of all dmx folders - in fact all folders and files - to remain untouched (unless of course I deliberately edit one). One specific issue I have in mind is the automatic updating of the Bootstrap css file.

I think it should be an option to create a project and not have to keep it up to date with the latest changes in Wappler. Of the 20 million or so websites using Bootstrap, I expect the majority are using neither versions 4 nor 5, and many may stay on their original version for years if not forever. I’m not suggesting Wappler should support all versions - I think the previous and current is enough. However, I think it should be possible for users to be confident when they open an old site - perhaps just to edit a piece of static text - that nothing will break.

#12

That is important. I agree. So having a “Don’t Update” button wont hurt.

1 Like
#13

Actually we plan to introduce versions for the Server Connect core and modules and let to update or not.

Much like the NodeJS modules versioning is already working.

So it is versions and dependencies per module, not Wappler dependent any more.

For NodeJS npm is already available for version control, but for PHP we will have to add something like PHP composer to do the same.

2 Likes
#14
#15

How will that work with the UI? What if a new version of Wappler has a UI change dependent of a some SC core change?

1 Like
#16

Good point indeed each new Wappler update bring some UI changes and improvements.

So it will be very difficult to mix old extensions with new Wappler and visa versa.

That is why we updated all at once now.

Having too much choice of versions will also limit us to move easily forward and introduce a dependency hell.

Now you can at least blame a bug on Wappler x.x while having different versions of the components will introduce so many more things to check and support.

That is why we haven’t done that yet and are still considering the best strategy.

3 Likes
#17

That’s why I didn’t participate yet until you mentioned it was in the plans. The amount of overhead this could create is to be considered.

To be honest, I really don’t think Wappler needs to change. It is the users that need to use GIT more so when they update they can review, ignore and cherry-pick changes.

4 Likes
#18

I don’t think this is relevant. I don’t think any extra overhead should be added and it wasn’t suggested that multiple versions should be supported. Eg I said:

If I create a site in Wappler today and come back to it after a year or two - perhaps to change a telephone number - with the way Wappler currently works, such a change could break the site. I think it would good to have the option of it not breaking the site.

#19

Wouldn’t that require dozens of UI iterations to be stored and maintained(to certain degree) plus the overhead of forum support requests?

On the other side I understand your point. I just think that the amount of work that has to be invested here isn’t justified.

2 Likes
#20

I don’t understand your point. I’m not suggesting there should be any additional backward compatibility with old versions. I’m just suggesting that it shoud be possible to open an old project in Wappler without any files being updated or replaced automatically.