Require `version` file? about alfred-workflow HOT 15 CLOSED

I think a file would be a good idea, but I would make it a JSON file including the github slug and all other related information as well. Maybe we should call it .workflow.json, .config.json or something like that.

from alfred-workflow.

To what ends? What if the workflow doesn't use GitHub or support automatic updates?

What's the benefit of a JSON file over a simple plain text file? In particular, why should it be a hidden file? That sounds like a recipe for disaster (it's not trivial to get Finder to display hidden files, and it's all too easy to forget that they're there).

Asking authors to write JSON files has a long track record of them fucking it up (see alleyoop).

I'd prefer to avoid asking workflow authors to hand-write JSON files unless there's a compelling reason to do so. In particular, while I think it's not an entirely terrible thing to require a plain text file with a version number, I'd be very hesitant to require that an author write a JSON file.

from alfred-workflow.

I vote absolutely yes to the simple, plain text version number. I'm with Dean here, one file, one function, nothing complex at all. Dean is absolutely right, we need better "best practices", and insofar as this library is quite popular, it could push that (currently almost non-existent) practice forward.

from alfred-workflow.

And again, you guys have a point!
Being a CS student myself, I sometimes forget about 'beginners' and how simple things can make a difference...let's stick to a simple version file including a version string only. I still hope that Andrew adds a version label soon.

from alfred-workflow.

Obviously, there are different levels of "require". What are we thinking?

The first would be "absolutely require", so that there should be a first-order check then error setup. What I mean is that Alfred-Workflow will check for a version file on instantiation. If one isn't there, Alfred-Workflow immediately returns an error and everything stops.

Alternatively, it could be a "partial require", whereby it is only required for certain functionality (the auto-updating features, one day to be in the master branch). But, for other features (like filter()) Alfred-Workflow won't fail if there isn't a version file.

If we are aiming to inculcate best practices, the first will clearly be better. If we want an ease of transition to the new Alfred-Workflow, the latter is better. I personally vote for option 1, but I'm entirely open to the other as well.

from alfred-workflow.

I'm tending towards a "soft" requirement.

If a workflow author wants to use functionality that requires a version number, such as auto-update, Workflow will immediately throw an error if passed update_settings without a version file present.

It shouldn't actually be required for any other functionality (the corresponding magic arg could just respond "Unknown version"), and I'm thinking more along the lines of trying to do workflow authors a favour than forcing them to do the right thing (I always forget to update the version number somewhere if it's in more than one place).

from alfred-workflow.

Well the "soft" requirement will certainly break less stuff, which is always a good things in an underlying library such as this.

from alfred-workflow.

BTW, I hope to push a self-updating version today, if only to develop (I'm still unsure what the best approach to version numbering is—do I insist on semantic versioning or not? Another "best practices" question …)

I just need to rejigger update.py so it can perform the download and install in the background, so I can show a status message when workflow:update is called.

from alfred-workflow.

FYI: https://twitter.com/fniephaus/status/515138366539825152

from alfred-workflow.

Good news!

from alfred-workflow.

So, I've been working on v2 of MailTo for a couple of days.

Because I haven't released it yet, the auto-update mechanism (totally sweet idea @fniephaus) keeps telling me to "update" to v1.4.1.

It confused me, and I helped write the code, so I think it's fair to call that confusing (and therefore bad) behaviour in general.

The obvious solution is to insist on semantic versioning. Is that reasonable? What do you guys think?

Would it be a better alternative to make the version comparison code smarter and have it ignore versions that aren't on GitHub?

from alfred-workflow.

Do you mean that it is confusing to see the update notice while developing a new version?

I believe it's okay to insist on semantic versioning, because that's how it should be done on GitHub anyway:

We recommend naming tags that fit within semantic versioning.
https://help.github.com/articles/creating-releases/

Besides, I think it's a good idea to ignore any leading v (so that v1.0 is equal to 1.0), but that should be all.

from alfred-workflow.

Exactly. I have 2.0 installed, but Alfred-Workflow keeps telling me to update to 1.4.1 because the version comparison code isn't very smart.

It is smart enough to remove a preceding v before comparing versions, however.

I reckon semantic versioning is the way to go.

OTOH, it's also been handy for the development of the workflow having it want to update itself all the time. I've found a couple of real bugs in the update code as a result.

That said, I can easily test that by temporarily declaring my development version to have a lower version number…

from alfred-workflow.

That's how I test my workflows as well. Let's stick to semantic versioning!

from alfred-workflow.

Okay. Semantic versioning it is.

I just pushed v1.9.3, which fixes a relatively serious bug with the update code (it would only recognise that a workflow had been updated for 60 seconds after retrieving the list of releases).

The next version, v1.10.0, will use semantic versioning instead of the current, rather dumb version comparison algo.

The version file idea is going on ice for now. As far as I can tell, it's not actually necessary for workflow authors to specify the current version in any place other than update_settings, which can avoid the problem of multiple version numbers in multiple places.

I'll come back to this if Alfred ever provides a version number in info.plist.

from alfred-workflow.