I noticed plugins that are hosted on Github all point to the "raw" link within the repo and nobody ever uses the release function in Github. I prefer to add artifacts as a release and not keeping them in the repo. Is it just a convention that someone started and everyone followed?

Edited July 12, 20241 yr by bobbintb

I think the assumption is that the plugin are going to be installed via Community Applications and so no need to use the gitHub release feature as long as you do whatever CA needs to see a new version?  Not sure what advantage (if any) using the Release function would give to the average developer.

18 minutes ago, bobbintb said:

I noticed plugins that are hosted on Github all point to the "raw" link within the repo and nobody ever uses the release function in Github. I prefer to add artifacts as a release and not keeping them in the repo. I tested using the link from a release and I got a server error. I'm assuming that's the reason developers don't do it that way and there is a redirect or something that the plugin installer doesn't like. Is that the only reason it is done that way? Is it just a convention that someone started and everyone followed?

I dont do releases.

2 hours ago, bobbintb said:

I noticed plugins that are hosted on Github all point to the "raw" link within the repo and nobody ever uses the release function in Github. I prefer to add artifacts as a release and not keeping them in the repo. I tested using the link from a release and I got a server error. I'm assuming that's the reason developers don't do it that way and there is a redirect or something that the plugin installer doesn't like. Is that the only reason it is done that way? Is it just a convention that someone started and everyone followed?

I use releases for the compose plugin and the swapfile plugin.

On 6/27/2024 at 6:52 PM, bobbintb said:

and nobody ever uses the release function in Github

I do that, but not for all plugins.

 

You can take a look at the Intel-GPU-TOP plugin for example here which is working just fine:

https://github.com/ich777/intel-gpu-top

 

My driver plugins utilize the Release section too for the driver packages, in combination with the "usual" packages directory for the plugin related files.

 

On 6/27/2024 at 6:52 PM, bobbintb said:

Is it just a convention that someone started and everyone followed?

I think it's this.

 

 

You also have to keep in mind that I have massive issues with users from China and the Release section or better speaking the API because by default I think it's blocked there. They have to use a proxy or VPN to circumvent that.

Since 99% of users won't ever visit the GitHub repositories, it's more convenient to just work inside the file tree for me.

On 6/28/2024 at 8:21 AM, Rysz said:

Since 99% of users won't ever visit the GitHub repositories, it's more convenient to just work inside the file tree for me.

Really? To each their own but I feel the release feature is more convenient. Well, maybe that's not the right word. The file tree is more convenient in the sense that it makes some things quicker and easier but I feel you lose a lot that way. I find management and change tracking more difficult because I have to sift through commits. The release, on the other hand, is a snapshot in time and, for me at least, just easier to conceptualize as a known verified reference point. Then you can always narrow your scope by sifting through releases. Especially for binaries, looking for an older version in the commits is a pain, as is keeping copies of every version in the file tree.

I'm curious, what about it do you find more convenient? I'm really just trying to assess if I just have a different preference or if there is something I am overlooking that would change my preference or make things easier.

On 6/27/2024 at 1:02 PM, primeval_god said:

I use releases for the compose plugin and the swapfile plugin.

Ah, I thought I was the only one! Glad it's not just me.

I use releases too, both for managing the current release of the plugin, and for building the packages that the plugin uses

4 hours ago, bobbintb said:

Really? To each their own but I feel the release feature is more convenient. Well, maybe that's not the right word. The file tree is more convenient in the sense that it makes some things quicker and easier but I feel you lose a lot that way. I find management and change tracking more difficult because I have to sift through commits. The release, on the other hand, is a snapshot in time and, for me at least, just easier to conceptualize as a known verified reference point. Then you can always narrow your scope by sifting through releases. Especially for binaries, looking for an older version in the commits is a pain, as is keeping copies of every version in the file tree.

I'm curious, what about it do you find more convenient? I'm really just trying to assess if I just have a different preference or if there is something I am overlooking that would change my preference or make things easier.

 

Since both binaries and plugin files are already packaged into the dated .txz files (archive/ and packages/), it seems just an unnecessary extra step for me.

I could picture myself using repository tags to "mark" a state of the repository with the release date, but the release feature really has no point for me.

If I want to look at what was in a specific version, I'll just decompress that package from there and have the file tree of that release for inspection.