v1.1.2

This is a minor update to fix an edge case that some users have run into in the past.

While Readwise does not impose any limits on how many highlights you can have, there is a system limit that highlights can't be any longer than 8191 characters long.

Generally speaking, if you're making highlights that long, you're missing the point of highlights but I've seen occasional reports of Kobo highlighting accidentally capturing an entire chapter.

Without this being obvious to the end user, they'll be confused when October appears to fail (as any error will cause the upload process to fail currently) so it's better to work around this issue than cause 99% of valid highlights to fail to upload I think.

The real fix for this is to delete those highlights on your device (find the highlight, tap it and hit delete) but for users who might want to make such long highlights for whatever reason, October will now split your highlight text into appropriate chunks.

What's Changed

• Split extremely long highlights by @marcus-crane in #62

Full Changelog: v1.1.1...v1.1.2

v1.1.1

This version adds a fallback for highlights that are missing the DateCreated field, which causes October to fail to continue processing.

In the event that DateCreated is missing, October will use the DateModified field. If both are somehow missing, it'll do a further fallback and use the current date.

What's Changed

• Support instances where bookmarks have no created date by @marcus-crane in #57

Full Changelog: v1.1.0...v1.1.1

v1.1.0

This release brings quite a few changes although a lot of them are under the hood so you won't notice them but they'll make it easier to add new features to October going forward.

Codesigning on Windows

First of all, October for Windows is now codesigned meaning there should no longer be any scary warnings going forward. As this version is the first to be codesigned, and my developer certificate is now, Windows SmartScreen is expected to appear for a brief period of time while trust is established against October but once that's done, new releases should no longer trigger a warning. You can read more about this addition in this announcement

Internal refactoring

As mentioned, a lot of changes have happened under the hood. October is powered by Wails and while understanding how to use the latest version, I rearranged the internals of the project and the latest iteration ended up with everything being a bit too far apart resulting in duplicate code and other things. Without boring you with the details, everything is now "closer together" making it easier to do changes going forward.

The frontend now also uses Vite and with that comes live reloading which means any developer changes will recompile the application. This means it becomes much faster to test out changes (and ultimately to release them as well!)

Support for unreleased Kobo devices

Under the hood, October uses pgaskin/koboutils which currently has support for all released Kobo devices. At one point however, it did not and it may lag behind when new devices are refreshly released. October effectively just uses koboutils to get metadata about devices so I've updated the device selector to allow you to select unrecognised Kobos instead of just ignoring them.

Condensed settings

The Settings page has been condensed a little bit and the Readwise token link will now actually open that window in your browser whereas before it was just a piece of text.

In future, I'd like to add the ability to both export and view system logs from within October itself for any advanced users who might like to try and diagnose their own issues.

Updated toasts

The library I was using for toasts wasn't the nicest so I've swapped out react-toastify for react-hot-toast which has cut down on a bunch of code. As a result, toasts now appear at the top of the screen and take up much less space visually.

What's next

As you'll notice, there wasn't much new in this release as a lot of it was spent on things behind the scenes. I think October is in a good spot to start extending out the UI so users have much more control over highlight uploading instead of just a big sync button.

As a bit of a teaser, here's a screenshot of something I threw together in a short period of time. I was starting straight on a v2 but I decided it's better (and safer) to do things piece by piece rather than doing a big bang release that may ultimately introduce more bugs. Admittedly, doing the best thing isn't as fun though.

This isn't necessarily what an updated October might look like but while this is using an email template, it is rendering real data from my Kobo that was connected to my computer. Ideally if one highlight fails, it shouldn't cause your entire upload process to be blocked so that's something I'd like to move towards next.

What's Changed

• Upgrade wails version and LICENSE year by @marcus-crane in #50
• Upgrade frontend to match Wails official Vite + Typescript template by @marcus-crane in #51
• Migrate to zerolog + begin to migrate items to a single pkg by @marcus-crane in #52
• Complete migration of all existing code to a single backend module by @marcus-crane in #53

Full Changelog: v1.0.2...v1.1.0

v1.1.0-pre2

• Replaced react-toastify with react-hot-toast
• Slimmed down the settings page by rolling the validate Readwise button into the save widget
• Add support for unreleased Kobos (although there are none at present)

Full Changelog: v1.1.0-pre1...v1.1.0-pre2

v1.1.0-pre1

The first pre-release of v1.1.0 which features a bunch of internal refactoring as well as Windows codesigning

What's Changed

• Upgrade wails version and LICENSE year by @marcus-crane in #50
• Upgrade frontend to match Wails official Vite + Typescript template by @marcus-crane in #51
• Migrate to zerolog + begin to migrate items to a single pkg by @marcus-crane in #52
• Complete migration of all existing code to a single backend module by @marcus-crane in #53

Full Changelog: v1.0.2...v1.1.0-pre1

v1.0.2

This release builds Windows versions with CGO_ENABLED=1, fixing #40 so October should now work for Windows users.

You might also note the disappearance of arm builds since they need a little more consideration to work. That and I don't think anyone uses Windows arm anyway but if so, feel free to file a request via the issues tab so I can gauge interest.

I'll try to test out any changes on Windows more often as I personally run on macOS but feel free to submit any issues for anything you spot.

Full Changelog: v1.0.1...v1.0.2

v1.0.2-pre2

This release disables arm64 builds which realistically aren't used, nor do they compile properly with CGO_ENABLED=1

Full Changelog: v1.0.2-pre...v1.0.2-pre2

v1.0.2-pre1

This release flips CGO_ENABLED=1 for builds as Windows builds apparently require this in order to access any given sqlite3 database.

Full Changelog: v1.0.1...v1.0.2-pre

v1.0.1

This release fixes a compilation issue in v1.0.0. Binaries should now be available 😅

Full Changelog: v1.0.0...v1.0.1

v1.0.0

This marks the first "official" release that I think is decent enough to release into the wild but it certainly won't be the last release.

Included in this release are the following new additions:

• Add the ability to upload cover images (NOTE: This requires some presetup with Calibre)
  • Cover uploading is off by default as it will result in confusing output for the user (blue covers) if they haven't followed the required steps
  • These aren't documented yet but will be shortly
• Add a button to check connectivity with Readwise
• Forward SourceURL which is the source file for a book. This is used in deduplication so eg; a different copy of the same book would result in different highlights.
  • This is used under the hood to map existing Readwise books to titles on device in order to upload covers from the device
  • This will result in existing Readwise uploads being duplicated one time! This is reflected in the jump to 1.0.0 to indicate a "breaking" change
• Enable the ability to load in locally stored Kobo sqlite databases. Mainly this is useful for myself when debugging so I don't have to plug in a Kobo all the time but it might be handy for any users as well.

In general, the app is solid enough to use hence why I'm marking it ready for v1.0.0 now despite it not being perfect. It's stable as far as what the user expects anyway, beyond the one breaking change here. I don't expect to change any upload code in future, besides say; a v2 of the Readwise API

As always, please file any bugs you discover

What's Changed

• Refactor October into separate packages by @marcus-crane in #31

Special Thanks

I'd like to say a special thanks to @jasondemeter for taking this project for a spin and pointing out some bugs along the way

Full Changelog: v0.9.4...v1.0.0