Closed vitorgalvao closed 2 years ago
@vitorgalvao Wow, thank you for this! I was considering migrating this workflow to Alfred 5 User Configuration, but I had a few reservations. With that, I have one main question to ask:
Will someone using this workflow on Alfred 4 lose any of their changed preferences by migrating to Alfred 5 with your changes in place? In other words, is the new Alfred 5 User Configuration UI backwards-compatible with the old env variable system? Or what would the user experience be? (e.g. do the preferences migrate seamlessly, or will they be prompted to re-enter values)
I noticed you made no changes to the workflow code itself, which I find encouraging in this regard, but I just want to make sure. I do see that there's a place to specify the variable name, so I'm guessing env variables are linked to these user config fields somehow?
In other words, is the new Alfred 5 User Configuration UI backwards-compatible with the old env variable system?
Yes. The user configuration sets environment variables, so as long as their names remain the same everything else will work. Checkbox configurations (Use Direct Zoom
, in this case) set the variable as the string 0
or 1
, but I have noticed in your code that you include a method for converting strings to booleans which takes 1
into account, so no change was needed.
Section 2 of Configuring your Workflow as a creator covers technical details, but don’t hesitate to ask if you have other specific questions.
@vitorgalvao I see. I'd prefer not to commit your updated binary by merging this PR (since it's not release-ready yet), so I'm actually going to close this issue and play around with things on my own. But I will definitely reference your changes, so thank you so much for submitting it regardless!
since it's not release-ready yet
What’s missing?
play around with things on my own.
However you prefer! If you have questions, feel free to ping.
@vitorgalvao
What’s missing?
Sorry, poor choice of words on my part. Your changes are fine as far as this PR is concerned. I mean to say that because the workflow binary on the main
branch is one of the primary means people download the workflow, I have to make sure I only commit an updated binary when I am also ready to release a new version of the workflow.
Otherwise, people may download from the main
branch when I'm not ready to publish the release yet. Committing the binary is usually the very last step I take in publishing a new release.
One solution for me is to create a "pre-release" branch for this PR to be merged into, like a develop
branch, but that's extra management I'm not sure I want to introduce right now. So for now, I'm more inclined to close this PR, download your code, and test it out myself until I'm ready to push a v5.1 or v6 release.
Does that kinda help explain my thought process here? 😅
@vitorgalvao Firstly, I just wanted to re-emphasize: thank you so much for contributing this! I'm sorry if I didn't make that clear earlier. 😅
Secondly, it does appear that upon installing the new workflow, any previously-set env variable values get overwritten by the default values enforced by the User Configuration panel. I can obviously re-enter my (previous) custom values, but I would need to know/remember to do that.
I suppose this is fine, but I need to decide if this constitutes a semver-major version bump (i.e. from v5 to v6), or if it's still technically a semver-minor version bump (i.e. from v5 to v5.1) given that they can still re-enter the values on install.
What do you think?
I'm sorry if I didn't make that clear earlier.
Not at all, it’s fine, don’t worry about it.
any previously-set env variable values get overwritten by the default values enforced by the User Configuration panel.
Ah, I see what you meant. Yes, because they’re now stored differently. You could share an intermediate version which translates the Workflow Environment Variable to the prefs.plist
, but I don’t think you have to worry about that. You have good defaults which I’d bet most people won’t change, and the ones who do will now have a clearer interface to do so.
For reference, in the official Alfred Workflows—including the popular 1Password and Google Drive ones—I've switched from Workflow Environment Variables to User Configuration without any intermediate steps and had zero remarks on that.
I need to decide if this constitutes a semver-major version bump
I can see the argument for both. In this case I’d go with 5.1, though I typically do calver. Server is important for libraries, but for stuff people use directly, like apps and Workflows, I found that no one cares as long as versions change. Versions end up being more useful for us to debug / make sure someone is on the latest than anything else.
Semver is important for libraries, but for stuff people use directly, like apps and Workflows, I found that no one cares as long as versions change.
@vitorgalvao Fair point. However, in addition to the fact that all of my other projects use semver, I find that semver keeps me more aware of the scope/impact of the changes I'm making, be it to a library or an application.
You have good defaults which I’d bet most people won’t change, and the ones who do will now have a clearer interface to do so.
With this argument, you have convinced me that v5.1.0 would be quite acceptable, and I think it makes sense given that v5.0.0 was recently pretty recently. In other words, a v5.1 release would communicate that this simply improves integration with Alfred 5, rather than being a more substantial upgrade (e.g. to a future Alfred 6).
And with that, I will begin adding the finishing touches to the User Configuration, and begin preparing for a OCU v5.1 release soon. Thank you for your thoughtful feedback!
@vitorgalvao Alright, I have released OCU v5.1.0 with the new Alfred 5 User Configuration. Thank you again for your help and feedback with this!
https://github.com/caleb531/open-conference-url/releases/tag/v5.1.0
Updated user configuration and About for Alfred 5. Had to submit the packaged Workflow since you don’t provide the info.plist in the repo. Attaching that one so you can take a look (has to be a zip because GitHub does not allow .plist attachments).