how to build VirtualBox .ova files on the server yet..
Are you trying to use the server instead of computer completely? So far I know it's called Nested Virtualization. Also, maybe it can be possible with the actual API for VBoxManage instead of the GUI.
I did try to do nested virtualization, but did not get it working yet, because I did run out of time. I'll try to continue sometime.
It's possible to run VBoxManage inside Docker also. I would presume it's possible to create .ova file with VBoxManage commands too, but I have not looked from VBoxManage docs yet.
Still, 7 release per day means customer have to download (at least something) 7 times per day. Think about it, how would it feel to download microsoft updates for whole day? ;)
If using snap, updates happen automatically, and there is only small break in Wekan usage when it reloads webpage.
If using Docker, and someone would want to test releases, I really can't expect someone spending time to deploy every release of those 7. Docker users would only deploy when they have time for it.
Microsoft updates are usually with forced reboots. There can be some delay added, but usually after that update is forced. This is the worst way.
Linux package updates can come anytime, but usually you can select when to install them. You can also disable updates. Some distros have option to do automatic updates.
Wekan Snap updates can be scheduled to happen immediately, or at specific time at night once.
Any Wekan Docker version can be installed manually, and install updates manually.
This is really popular way to deal with development features, In fact most other companies does this. They often release to development branch. The users can either use the stable version and only update when there is another major/security update. The curious users can use development version and use the latest features.
Ubuntu has two release channels, well, normal users know of it as LTS and non-LTS. LTS is well tested, non-LTS is not.
Chrome has canary and dev channel.
The list can go on. This is least stressful way to deal with releases.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
github.com/wekan/wekan/wiki/FAQ#wh...
I did try to do nested virtualization, but did not get it working yet, because I did run out of time. I'll try to continue sometime.
It's possible to run VBoxManage inside Docker also. I would presume it's possible to create .ova file with VBoxManage commands too, but I have not looked from VBoxManage docs yet.
Still, 7 release per day means customer have to download (at least something) 7 times per day. Think about it, how would it feel to download microsoft updates for whole day? ;)
If using snap, updates happen automatically, and there is only small break in Wekan usage when it reloads webpage.
If using Docker, and someone would want to test releases, I really can't expect someone spending time to deploy every release of those 7. Docker users would only deploy when they have time for it.
Microsoft updates are usually with forced reboots. There can be some delay added, but usually after that update is forced. This is the worst way.
Linux package updates can come anytime, but usually you can select when to install them. You can also disable updates. Some distros have option to do automatic updates.
Wekan Snap updates can be scheduled to happen immediately, or at specific time at night once.
Any Wekan Docker version can be installed manually, and install updates manually.
And that's why all big guys focus on major releases. And linux gives way to install only major updates too.
Maybe the developers at windows are thinking the same,
It's not mainly about productivity. New releases often have important bug and security fixes.
I do still remember at the beginning of starting to maintain Wekan, that someone asked could I do releases, so I figured it out.
I have not yet learned how to do separately stable release.
Snap has 4 channels:
Currently when I do releases, I:
sudo snap refresh wekan --edgesudo snap refresh wekan --stable --amendBut how it would work, if I would mostly develop at edge, release to stable less often?
There could be different GitHub branches for these channels. Also with Docker it would be possible to select which Docker image and which tag to use.
Wekan does not yet have plugin system:
github.com/wekan/wekan/wiki/FAQ#is...
Maybe it could be like in git feature branch workflow:
atlassian.com/git/tutorials/compar...
So for example, I could have have this workflow:
Would this work?
Or would something else work better? Anyone?
This is really popular way to deal with development features, In fact most other companies does this. They often release to development branch. The users can either use the stable version and only update when there is another major/security update. The curious users can use development version and use the latest features.
The list can go on. This is least stressful way to deal with releases.