search

YunoHost-Apps / rss-bridge_ynh

RSS-Bridge package for YunoHost
https://github.com/RSS-Bridge/rss-bridge
The Unlicense
15 stars 6 forks source link

Grab the files from the RSS Bridge master directly #54

Open tio-trom opened 1 year ago

tio-trom commented 1 year ago

I am wondering if changing directly to the master/main branch in this manner is ok since we can do it whenever we desire to keep this package updated. No need to use commits. Simply use the main branch and from time to time easily change the shasum and the ynh versioning number and we are done. RSS Bridge does not have releases anymore. And this ynh package is not updated in a year or so.

tio-trom commented 1 year ago

Ah it will not work since the shasum wont be the same if there are new commits....damn.....is there a way around this? What if we do not use shasum for this and skip it?

tio-trom commented 1 year ago

Will first make sure if they plan new releases or not rely on that anymore. Then we can switch to a commit instead of the master branch directly. Will update it all here.

lapineige commented 1 year ago

RSS Bridge does not have releases anymore

Oh that's why I didn't receive any notification.

What if we do not use shasum for this and skip it?

Certainly not. That introduce a security breach for all users.

Ah it will not work since the shasum wont be the same if there are new commits....damn.....is there a way around this?

One time-consuming but relatively easy to implement option is to make the release archive ourselves from time to time, based on a dedicated commit.

tio-trom commented 1 year ago

So we can use commits for sure like so "https://github.com/RSS-Bridge/rss-bridge/archive/4e616c7092b0fa2ad181117817ab80ad6cf4dfef.tar.gz" - I opened a discussion over here https://github.com/RSS-Bridge/rss-bridge/discussions/3322#discussioncomment-5360241 let's see what the RSS Bridge devs are saying. But I suspect the saner way is to pull from commits else their release cycle is so slow that it makes this service unusable in many ways.

tio-trom commented 1 year ago

Any updates about this? My instance does not work properly and the RSSBridge devs said it might be because they always fix things and our package is really old. Let's try to pull from git master please. If you guys can implement this I can for sure change the commit numbers and ynh versioning every so often so that we have an updated version of RSS Bridge. https://github.com/RSS-Bridge/rss-bridge/commits/master

tio-trom commented 1 year ago

And I think the package naming should be easy. Take this: 2023-09-13_13-47

Can be the date of the commit. 2023.09.13~ynh1

lapineige commented 1 year ago

Can be the date of the commit. 2023.09.13~ynh1

That's the usual procedure, yes.

and the RSSBridge devs said it might be because they always fix things and our package is really old

Do they plan to use releases (again ?) or will they stick to a rolling-release style on a main branch ?

lapineige commented 1 year ago

Strangely the error you report with Youtube bridge does not happen in my case. Which version of the package are you using ?

tio-trom commented 1 year ago

Do they plan to use releases (again ?) or will they stick to a rolling-release style on a main branch ?

I do not know but for such a package pulling from master seems like a better idea since many sources may not play well with RSS and these devs are fixing a bunch of things. Same with SearxNG - and it is good that YNH pulls from git directly (from my understanding).

Strangely the error you report with Youtube bridge does not happen in my case. Which version of the package are you using ?

As it was mentioned in that issue it could be because my instance is more popular but recent RSS Bridge changes may bypass that. I will have to check with the latest from master as it was suggested, to find out the cause. My version is 2023.07.13~ynh2

lapineige commented 1 year ago

Do they plan to use releases (again ?) or will they stick to a rolling-release style on a main branch ?

I do not know but for such a package pulling from master seems like a better idea since many sources may not play well with RSS and these devs are fixing a bunch of things.

The thing is it introduce a constant burden of maintenance to watch for changes, decide which commit to use, upgrade the package and test it. If that can be avoided in favor of an upgrade to a new (stable) release every few months, for my part I would clearly not choose to put a significant extra energy trying to upgrade the package (except for security fixes maybe) roughly all the time. That said, if someone is willing to do these upgrades and test them manually all the time, fine. One could also push them to a custom branch / testing on a regular basis to provide the latest commit to people willing to try at their own risk, without providing extra testing (this would not be merged into master). I've nothing against it.

tio-trom commented 1 year ago

From what I understand their official instance runs from master. So should be ok.

lapineige commented 1 year ago

So is that master branch the "stable" one, where few development happen, or is that just that the official instance serves for testing purposes too ?

tio-trom commented 1 year ago

Now that they are doing releases more often lets stick to that! Should we close this for now?