Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automated notice for outdated packages in Bonsai #1974

Open
cjsha opened this issue Aug 13, 2024 · 3 comments
Open

Automated notice for outdated packages in Bonsai #1974

cjsha opened this issue Aug 13, 2024 · 3 comments

Comments

@cjsha
Copy link

cjsha commented Aug 13, 2024

There is some software from whom I look forward to their updates (Bonsai being one of them, KiCAD, docfx, etc.). I'm hoping Open Ephys Bonsai packages will belong in that category for users.

However, it's easy to fall behind on updates if I'm not notified they're available. For that reason I suggest an opt-in feature in Bonsai that notifies users if a package is outdated. It would be opt-in to avoid annoying users. Moreover, you could do opt-in on a per-package basis. The idea is that we would recommend users to opt-in in our Bonsai Installation & Configuration Guide so they can know there are new features and big-fixes available.

I'm not sure if there is a way to bring this into Bonsai easily. But if so, I wanted to bring it up to y'all so you could consider it.

Thanks!

@bruno-f-cruz
Copy link
Contributor

I am not sure I would do it via bonsai. Packages may be provided by third parties and I don't think bonsai can (and probably shouldn't) be dependent on those.

If an user is interested in updates I would probably push to rely on the package manager to check if available versions of the installed dependencies are available (which already happens) or have users explicitly subscribe to releases in the repository of the package.

@PathogenDavid
Copy link
Member

A potential issue with doing this is surfacing information about what the new version actually does for people.

NuGet's metadata actually does contain a releaseNotes field, but as far as I know we don't currently surface it anywhere on the UI (I actually forgot this field existed within NuGet, I don't think it's widely used even outside of Bonsai.)

Using this field would also put an extra burden on package maintainers. (For example, the strategy and tools we use to write the release notes for Bonsai's core packages would have to change entirely.)


I think it might be better to instead encourage people to subscribe to releases on GitHub for the packages most relevant to them.

If you go to the main page of a repo and click Watch then select Custom you can opt-in to being notified about releases.

Depending on your GitHub notification settings, you'll receive an email or a GitHub notification whenever watched repositories publish a new release.

Right now it's a little tedious to get to the GitHub project page for a given package, but this is something we're already working to improve for 2.9.

@cjsha
Copy link
Author

cjsha commented Aug 16, 2024

@bruno-f-cruz that makes sense to me. Though I wasn't necessarily suggesting that Bonsai would depend on updating external packages, it would be an optional opt-in checkbox when installing a package. It might also be nice as far as letting people know about the latest version of Bonsai too. There is some software where I'm leery to update, but (like I mentioned in the original post) I'm keen on Bonsai updates because new features and bug fixes are almost always incredibly helpful.

@PathogenDavid provides a decent alternative, though I think there are some caveats that might not make it worth it for us. In particular, it might be asking too much of our users who might not even have a GitHub account. The person using the package might be not the same person that installed the package and followed the instructions to subscribe to Github notifications. Last, I think it increases likelihood of people of forgetting to update because they'll likely receive the notification while away from Bonsai. Anyway, I do think it's a good idea, but it seems the first caveat alone is sufficient for it to be vetoed by my colleague.

Thanks for y'alls replies! I really appreciate it. This discussion alone is sufficient closure for me, but I'll leave this issue open for y'all to close in case there are any other ideas or comments anyone would like to add. Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants