Open Zheaoli opened 10 months ago
@Brooooooklyn Would mind taking a look at this proposal when you get time?
We can discuss about the detail in the issue
I used affine beta with Appimage on linux, basically it works well.
We have Homebrew cask for our stable version, so I think we only need to consider the Linux distibutions https://formulae.brew.sh/cask/affine
On Windows exist Chocolatey and Scoop
I'm familiar with Scoop, this project meets the criteria to be accepted on the extra bucket (buckets are repos with apps, and the extra bucket is for GUI apps). I can make a manifest and then add a PR to Scoop's extra repo so Affine can be on Scoop
Sorry for the delay I have some updates:
There is already a PR for Affine in the Scoop Extras repo, but this one was for version 0.7.2 and that one installed Affine from the .zip file.... Well, that .zip file no longer exists since version 0.7.3.
This "new" installer has a strange behavior (for me) in the installation. normally what scoop does is to take a portable version of an app or the executable and place it inside the scoop directory, this way scoop can manipulate the app (to update or remove it, etc...) but I don't know how to adapt this installer to what scoop expects.
It reminds me of the chrome installer (somehow) so I checked the chrome manifest in scoop (the file with the installation steps) and discovered that using an argument it is possible to manipulate the behavior of the installer, in this case to place the app data inside the scoop directory. Does the Affine installer have some arguments to manipulate the data? or where can I learn about how the Affine installer works in order to understand the behavior to see what I can do?
🙋 Upvoting
We are currently evaluating demand for the issue and checking whether it requires complicated or risky changes. Please leave a vote or comment if you think it should be prioritized.
This is an automatic reply by the bot.
Added to scoop's Extras bucket (ScoopInstaller/Extras#11734):
scoop bucket add extras
scoop install affine
@aliesbelik thank you :)
Description
For now, We release the binary file by using the GitHub release page. And the people may need to download the binary manually.
So I propose here to release the binary file to the package manager for different platform.
The following is the design detail
Pre Step
Release Interval
We will release two different binary
Platform release
MacOS
The arch we will release binary for are
Or maybe we can release a universal binary?
We will choose the homebrew as our target package manager.
We may need to maintain a tap repo on our own, like https://github.com/wez/homebrew-wezterm. So we just need to patch the version and checksum field in the file in the release workflow and commit it. All the processes would be automatic.
Linux
Linux release is a little bit different. There are too many distributions, so we need to decide to choose the distribution we will take care of. I think the following distribution would be great.
The arch we will release binary for are:
For ubuntu, the electron has supported the official Snapcraft release plugin. FYI: https://www.electronjs.org/docs/latest/tutorial/snapcraft , I will investigate it if it works or not
For Arch Linux, we need to maintain a git repo like https://github.com/Zheaoli/linux-xanmod-manjusaka.So we just need to patch the version and checksum field in the file in the release workflow, commit it, and push it to the aur repo. All the processes would be automatic.
I think the package name should be:
Windows
I'm not sure we need to support windows package manager.
Use case
No response
Anything else?
No response
Are you willing to submit a PR?