loading...

Discussion on: Confessions of an Open Source contributor

Collapse
entrptaher profile image
Md. Abu Taher 👨‍💻

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? ;)

Thread Thread
xet7 profile image
Lauri Ojansivu Author

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.

Thread Thread
xet7 profile image
Lauri Ojansivu Author

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.

Thread Thread
entrptaher profile image
Md. Abu Taher 👨‍💻

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,

more updates = more releases = more productivity

Thread Thread
xet7 profile image
Lauri Ojansivu Author

It's not mainly about productivity. New releases often have important bug and security fixes.

Thread Thread
xet7 profile image
Lauri Ojansivu Author

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:

  • stable
  • candidate
  • beta
  • edge

Currently when I do releases, I:

  1. Merge develop branch to master
  2. Build snap package
  3. Release snap package first to edge
  4. Test it with sudo snap refresh wekan --edge
  5. If it works, release it to all channels
  6. Change my server to use stable channel with sudo snap refresh wekan --stable --amend

But 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:

  1. Feature would be in it's own feature branch.
  2. I merge feature to devel branch.
  3. I release devel branch to snap edge.
  4. When feature works well enough, I would merge feature to stable.

Would this work?

Or would something else work better? Anyone?

Thread Thread
entrptaher profile image
Md. Abu Taher 👨‍💻

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.