Closed ranetto closed 8 months 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.
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.
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
...
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!
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.
I share the desire for a changelog, but also understand @jcsteh's restraint. Some alternative ideas:
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.
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.
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.
Honestly, I don't know. I'll leave this open, but I don't see a clear path forward here.
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.
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.
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?
Doesn't an updater impose the same problem that distributing via Reapac introduces?
I'm thinking that with our own updater, we'd download the existing installer for the relevant platform, which already does key map management.
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.
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