sparkle-project / sparkle-project.github.io Goto Github PK

https://sparkle-project.org/documentation/gentle-reminders

Thanks to sparkle-project/Sparkle#727, https://sparkle-project.org now works. Would be good to make https:// the default by:

1. 301 redirecting http:// to https://;
2. adding appropriate HSTS header with long max-age;
3. adding sparkle-project.org to HSTS preload list at https://hstspreload.appspot.com

Can we remove the alternative instructions for Cocoapods or clearly mention that those instructions only could possibly apply to a really old version of Xcode at this point? Xcode can code sign Sparkle when copying the framework just fine without a run script.

See this issue for more detail and how it can even cause trouble.

Update website documentation for sparkle-project/Sparkle#2285

For apps opting into hardened runtime / library validation, they will need to use a development certificate, or disable library validation for Debug configurations. We should document this on the website properly.

Refs sparkle-project/Sparkle#2056

Add SPM banner button onto main website.

Show how to add a 2.x prerelease from Xcode.

Show how users can reference other binaries / XPC Services we distribute in the package.

It would be nice to specify somewhere in the documentation what user agent string we send for analytical reasons, or for determining server side what feed to serve sometimes.

The delta update compatibility table formatting should be fixed/improved.

https://sparkle-project.org/documentation/delta-updates/

ARC is no longer supported.
macOS version should go up to 10.13.
Xcode version should go up to 9.3.

Update minimum system version requirements for website documentation. Related: sparkle-project/Sparkle#2196

It looks like this is being generated on build time here:

https://github.com/sparkle-project/sparkle-project.github.io/blob/master/_layouts/default.html#L87

…so a simple rebuild + deploy should bump 2019 -> 2020.

In 2.2, we're renaming the XPC Services (#2096) and will need to update the website docs.

https://sparkle-project.org/ claims:

Modern

Sparkle is kept up to date with the latest Apple technologies: it uses ARC and Auto Layout and supports macOS versions 10.7 through 10.11 and Xcode 5.0 through 7.0.

Those macOS and Xcode versions are far from being modern. My machine is currently at

macOS 10.15.5 19F101
Xcode 11.5 11E608c

Please update the website to reflect reality. Maybe just say "macOS 10.7 and Xcode 5.0 or newer"...

Regarding sparkle-project/Sparkle#2315, add documentation for new sparkle:format attribute and how to use plain text release notes.

documentation/preferences-ui/ states "choose Updater from the popup, and set the Model Key Path to updateCheckInterval." However, if you try this, you'll get a friendly error on the bindings panel and then a nice crash if you ignore it. The selectedTag binding expects to be bound to a NSNumber but updateCheckInterval is NSTimeInterval.

Options:

1. Tell me something I don't know about convincing this to work (and update the docs). This is my hopeful answer.
2. Remove this from the docs.
3. Add something to SUUpdater to is bindings capable (I can open a separate bug against the main project if you wish).

I've worked around this for now in code, but wanted to point it out.

The https://sparkle-project.org/ front page download button still says v1.20 though the latest release seems to be 1.21

Apple added this new font-family value -apple-system to Safari 9 and iOS 9, which renders the text in the system typeface. This is a great way to get San Francisco. I think it looks a bit better alongside the screenshot on the front page and is easier to read on non-Retina devices (Helvetica Neue looks pixel-y when very thin). On Yosemite (with Safari 9) this value defaults to Helvetica Neue, on Mavericks to Lucida Grande and in every other browser it is simply skipped.

https://webkit.org/blog/3709/using-the-system-font-in-web-content/

The only real downside is that Mavericks will be saddled with Lucida Grande. What do you think?

Due to the changes in sparkle-project/Sparkle@d4843c9 , applying delta patches was broken and could cause a crash. This only affects version 1.10 (I think) and also note that the issue was not within BinaryDelta tool itself, but in Sparkle's updater.

Or for simplicity sake, I suppose we could just say don't use binary deltas prior to version 1.11.

We should document that this feature exists, how to use it, and potentially how to test it, on the #publishing-an-update page

It might expect a particular pubDate date format and if I recall there were one or two specified parameters. And one of them is hardcoded.

Sparkle versions below 1.25 had some defects, but I don't think any were negative enough to necessarily be worth mentioning.

cc @fjaeger

The new site looks great. Congrats!

I just noticed that on the About and Documentation pages, the blue header at the top has rounded corners, while on the index page it does not.

Wasn't sure if that was intended or not, since to me it seems inconsistent.

I disabled CI validation of generated API documentation website from jazzy in e10765f

Issues I remember running into:

• there is a closing div tag at the end that doesn't match any earlier div tag (need to report upstream)
• img tag has no specified "alt" attribute; one example is carret image. looks like jazzy is wrong here and it's required.
• xml linter doesn't like the defer attribute missing an explicit value in the javascript script tag or something. I think the linter is wrong here..
• linter didn't like © or something for copyright symbol, not sure why.
• linter doesn't like <meta charset='utf-8'> line, maybe because it isn't closing with />.. But I think linter is wrong here, and HTML is valid.

A user of my app complained that the update process is too intrusive, and asked for the ability to download now but install the update on next launch. In retrospect this seems like the best way to do updates, so I looked around but I don't see a way to do that. There is some code that alludes to this ability (various methods with willInstallUpdateOnQuit), but it seems to be more an implementation detail of the multiprocess architecture than a user-facing feature.

What I'm proposing is a config flag to replace "Remind me Later" with "Update on Restart". This is like a one-time version of "automatically download and install updates in the future". Here's the proposed user interface:

When selected, the update would be downloaded immediately. On next launch, the app will install the download and relaunch itself.

If a new version becomes available after selecting "Update on Restart", the user would be prompted again (since the changelog would be different).

From reading the code, it looks like closing the window is equivalent to "remind me later", so no functionality is lost (although it's not obvious that it works this way, which is why this change would be opt-in).

Apologies if I've missed something in the docs or code. I really did try to research this before writing this issue.

We should update the page to include that we handle / ignore custom icons when applying patches (but when creating we forbid these).

Refs sparkle-project/Sparkle#2114

We can add some text for advising and using Swift Package Manager. The website currently recommends cocoa pods in step 1, but we should likely favor SPM over it.

cc @thebluepotato

AFAIK we're not sending any emails from that domain, so we can state that in SPF.

sparkle-project.org.  IN TXT "v=spf1 -all"

Use: https://api.github.com/repos/sparkle-project/Sparkle/releases

It should be the first release that isn't a draft or pre-release.

Add documentation for de-emphasizing past releases as part of sparkle-project/Sparkle#2373

I think this should be on https://sparkle-project.org/documentation/publishing/ page after the "Full release notes" section.

Section title could be De-emaphasize past releases or something similar. Not sure if it should favor opacity: 0.5 or display: none as an example, or maybe choose the more preferable one for demonstration, and comment that the other is possible.

It maybe should mention this feature requires Sparkle 2.5 (beta) but it is also backwards compatible with older releases anyway (no harmful effect).

At least for the update-api-reference GitHub action, we should have an option to specify which branch (or tag?) to checkout from sparkle-project/Sparkle

When I'm done with the jazzy documentation in the 2.x repo, we will need to push the html directory onto the website and update all API references to point to there. We'll also need to simplify the API reference page for 2.x to point there.

Related: sparkle-project/Sparkle#1910

For sparkle-project/Sparkle#2119 , need to update pasted help usage.

Add documentation for file system (HFS+) level compression.

Add documentation for new delta update attributes introduced in sparkle-project/Sparkle#2231

We should make a github action workflow to update the API reference documentation from Sparkle.framework

It would probably clone Sparkle's source code and the website repo, run make docs in the source repo, and cp documentation/html output to documentation/api-reference in the website repo, then create & push a new commit.

Add documentation for sparkle-project/Sparkle#2393

Hello,
I'm a Front-End Developer and UI/UX designer. I want to contribute to the website. Therefore, how can ask or have permission to make Sparkle website more beautiful?

Note: I don't want to change the layout. I just want to improve UI/UX

Hello, on the documentation page for Preferences UI bindings
https://sparkle-project.org/documentation/preferences-ui/
there are some copy-paste mistakes I think. The last two steps in binding the Update check interval settings still refers to the checkbox and key for automaticallyChecksForUpdates, instead of the popup menu and updateCheckInterval key.

Also, perhaps a list of the available Model Key Paths and their types could be a nice addition here? Their names don't seem to be the exact same as the .plist keys the current page link refers to on https://sparkle-project.org/documentation/customization/#infoplist-settings

On the website we have

For creating a LZMA compressed archive with optimal compression (supported on macOS 10.11 and later), tar can be used for updates instead:

But I believe it was supported on earlier OS versions (10.9).

Need to double check.

Our update settings docs which haven't had much love should not recommend instantiating an updater in the nib, which likely leads to making wrong design decisions about where to instantiate/store the updater. Instead, we should recommend passing the updater as a property/ivar instead and still hook it with bindings.

Avoid placing your app inside another folder in your archive. If you ship an archive that is not a dmg on your product’s website, which we do not recommend, the archive should then not contain multiple items. An exception to this guideline is if you use a signed dmg, but please be careful - the system may not warn you if the dmg is not signed properly!

I don't understand what DMG signing has to do with folders. This paragraph is complicated.

Apart from that:

• App translocation applies to unsigned DMG and ZIP/tarballs, so we don't recommend those for product's website.
• DMG is slow and hacky in Sparkle, so we shouldn't recommend it for update archives.

Should we change recommendation to:

• Use signed DMG on the website.
• Use tarball for Sparkle.
• Use tarballs for everthing if you can't sign the DMG?

Can you update sparkle support for Xcode 8? The tutorial is obsolete.

In Build Settings tab set “Other Linker Flags” to -Wl,-rpath,@loader_path/../Frameworks.

I don't ever recall having to do this, and I just created a new Xcode project and didn't need it.

Apps that specify HTTP addresses for appcasts (and are linked to the 10.11 SDK?) can't update under 10.11 unless they add an exception for the domain to their Info.plist files ("App Transport Security has blocked a cleartext HTTP (http://) resource load since it is insecure."). That seems like an issue that should be mentioned fairly prominently in the docs.