jcsteh / osara

OSARA: Open Source Accessibility for the REAPER Application
GNU General Public License v2.0
127 stars 46 forks source link

Osara what's new #372

Closed ranetto closed 8 months ago

ranetto commented 3 years ago

Hi James, I ask you if it was possible to add a small "what's new" to inform users of the new version of the version they are installing on the page from which you download osara, or within osara itself, perhaps where you accept the conditions. This thing is requested of me by many parties and I confess that I too, while following the "commits", often I cannot understand all the innovations introduced. What do you think about it? Can we somehow help you do this? I thank you in advance: Stephen

ScottChesworth commented 3 years ago

I'll pop a +1 on that. It gets asked about very often, and seems like having a way for users to keep track of changes in layman's language would cut back the amount of support I'm doing a ton, which would be a most welcome development.

jcsteh commented 3 years ago

I'm really not sure how that would work. Usually, each new snapshot only has a single new change. And since there are sometimes multiple snapshots in a week, it wouldn't be useful to just show the changes from the last snapshot, nor the changes without version numbers. And if I include changes with version numbers, well... at that point, you may as well just read the commit history. Generally, I try to provide a user facing description of any change in the commit message, unless it's not relevant to users, in which case I generally explain that.

jcsteh commented 3 years ago

I'm looking at the commit log and I really don't see how I can be clearer than this:

Commits on Nov 16, 2020

When moving to a track, report if there are track notes. Fixes #369.
8e2a70c 

Optionally move relative to the play cursor for time movement commands during playback. (issue #367, PR #368)
This is configured via the OSARA Configuration dialog and is disabled by default. For now, it affects scrubbing and moving by bar/beat. This also reorganises the Configuration dialog slightly.
4e79ad0 

Commits on Nov 13, 2020

Add OSARA: About action to display version number, etc. (#366)
8dad751 

Pressing the OSARA commands to report muted/soloed/armed/input monitored/phase inverted tracks twice presents them in a dialog with a multi-line text box for easy review. Re #243.
0e7e568 

...
ranetto commented 3 years ago

Hi James, of course the commits are pretty clear to me, but keep in mind that a lot of people are just musicians or engineers and don't follow the development directly like us: I believe that for those who install all the new versions even just the indication of the latest news of that version could be helpful. Maybe, if not in osara it might be helpful to put just two lines before the link from which you download osara, such as those that are on the reaper "download" page. What do you think about it? Thanks always for everything you do!

jcsteh commented 3 years ago

REAPER versions are different in that they have many changes per version. OSARA snapshots have generally one change per snapshot. Also, REAPER isn't open source, so you can't see the commit log. In contrast, for OSARA, you can just visit the commits page and see all the commits going back as far as you like.

The NVDA snapshots page provides a link to the GitHub commits page. We could do the same for OSARA, which should effectively give you what you want. That way, people don't need to bookmark the URL to the commits page or whatever.

LeonarddeR commented 3 years ago

I share the desire for a changelog, but also understand @jcsteh's restraint. Some alternative ideas:

  1. The commits page might be a bit difficult for people to read, since it contains commit hashes, links to the file tree, etc. May be the snapshots page could show the last 20 commits in a simple list with only the messages? How difficult would that be to build?
  2. Have a github hook that automatically updates the changelog based on the commits history. That would lead to a pretty messy commit log, though.
  3. Similar to NVDA, how easy would it be to hook up an OSARA groups.io and have commit messages on there on push? I think it could be pretty interesting for people to follow. I tend to watch the repo, but then you're still missing commits that are directly pushed to master.
jcsteh commented 3 years ago

I've been thinking about showing the last 20 commits or similar on the snapshots page as you propose. The problem with excluding commit hashes is that then there's no indication of what version introduced a change. The numbers generated by AppVeyor are not something I can fetch easily.

I guess an email list is possible; that would require a commit hook, since GitHub's commit email notifications are awful. Then again, people could just as easily use the RSS feed GitHub already provides for commits and get notifications in whatever way they choose.

jcsteh commented 3 years ago

The other alternative is to finally do official releases and have a change log for those. I'd only want to do those every 6 months or so, but maybe some users would be happy to wait that long in exchange for certainty, nice change logs, etc.

ScottChesworth commented 3 years ago

The other alternative is to finally do official releases and have a change log for those. I'd only want to do those every 6 months or so, but maybe some users would be happy to wait that long in exchange for certainty, nice change logs, etc.

Hmmm, how likely is that to fragment support though? As things are now, there's a stock response of "just grab the latest snapshot and we'll figure it out from there" available whenever I spot behaviour that indicates an out of date snapshot is in use. I wouldn't want users missing out on the excellent work you're doing because of perception that snapshots are less reliable or only for power users.

I wonder, if I were to write an article for the wiki or perhaps record a demo of how to smash through the developer-centric aspects of the commit log, would that solve it (at least to some extent)? It doesn't seem like a particularly difficult page to navigate here so long as you're comfortable just tuning out stuff you don't really need to read as an end user.

jcsteh commented 3 years ago

Honestly, I don't know. I'll leave this open, but I don't see a clear path forward here.

tbdalgaard commented 3 years ago

I give a +1 for the official release of OSARA.

Then people who like to test bleeding edge code can do so, and people who are needing OSARA in a production environment can stay on the official release.

That would also allow for more time to test experimental features out without having to deal with the support if something breaks.

Normally I would download and install every new version of OSARA whenever I check the snapshots page, but after something broke my Reapack after an OSARA update I haven't updated OSARA for a while, since I had to recreate all my custom scripts again.

ScottChesworth commented 2 years ago

I give a +1 for the official release of OSARA. Then people who like to test bleeding edge code can do so, and people who are needing OSARA in a production environment can stay on the official release. That would also allow for more time to test experimental features out without having to deal with the support if something breaks.

That rationale works for busier development cycles where there can be significant differences in the stability of snapshots versus official releases, but that's not what we're dealing with. Here, changes and/or new features don't get merged to master (released as a snapshot) until they're not considered to be bleeding edge. Sure, once in a blue moon a bug will slip through the net, but 1) that's rare, and 2) typically those issues get fixed fast.

ScottChesworth commented 2 years ago

Bumping this thread because I'm still getting requests, in particular around some sort of update feature. I'm wondering, could I sponsor someone's time to write us an updater?

LeonarddeR commented 2 years ago

Doesn't an updater impose the same problem that distributing via Reapac introduces?

ScottChesworth commented 2 years ago

I'm thinking that with our own updater, we'd download the existing installer for the relevant platform, which already does key map management.

jcsteh commented 8 months ago

As of #619, we have an update check function and it includes the commit log since you last updated in plain text. This isn't going to tick every box for everyone, but i think it's the most pragmatic compromise at this stage.