Greetings! Die-hard Logseq user, but also have a brain that does not begin to function in a database schema, so I am going to be sticking with markdown files forever.
I only just realized today that development of “Logseq OG” formally split off into its own GitHub repo at GitHub - logseq/og: Logseq og (file version) · GitHub, and I need to know how to switch to getting my updates there.
I have been using the flatpak version of Logseq, which I recently had to revert back to 0.10.14 because of PDF rendering errors introduced in 0.10.15, and I’ve also masked Logseq from flatpak’s updates so that shouldn’t happen again. I’m running Ubuntu 24.04.
I can see that an actual 1.0.0 release came out just two weeks ago! That’s very exciting to me. But I don’t know how to make the switch safely and it’s VERY important to me that I not break anything in the process, because I depend quite heavily on Logseq for my day-to-day work.
Can I get some guidance on how to do this properly? I’m reasonably technologically proficient, but not a developer or anything like that.
1.0 is the DB version now, so if you want to stick to the “OG” version I think the flatpak mask is the move until maybe there is an “OG” flatpak version.
@smeej will say that you don’t have to change your logseq brain to use the db vs the og version (i made the switch myself after a long time on MD files)
but if you’re set on that path- there shouldn’t be any issues upgrading from your current logseq to the current OG build. it primarily bumps versioning and some security fixed. always good practice to back up your files in the event you need to revert though
@jar Yeah…I tried. I get that most brains probably work fine in the two different ways. Mine straight up does not. It’s like a short-circuit. I don’t understand why. Same thing happens when I try to use Notion. I’ve lost jobs over it, despite my best efforts. I just absolutely can’t get there.
But I don’t need to, thanks to OG version! There are enough issues open for OG 1.0.0 that I don’t want to switch just yet, especially because it’s not clear to me what the right way to do so would be, but I am hoping for some kind of formal guidance to come out that will basically help the markdowners among us make one, nice clean step over to the new update track and live happily ever after.
@jar I wish I knew. If I understood what was breaking in my mind and why, I’d have an approach to fixing it. There’s just a different connection paradigm when things are connected in a database than when they’re connected in text. Things have properties and relationships and…I don’t even know what the problem is.
All I know is that I’ve beaten my head against the wall of trying to figure this out for dozens of hours over mulitple years, in cooperation with several people who are otherwise very effective at helping other people make the switch, and it hasn’t worked at all. Since I don’t need to keep trying, I’m not going to!
OG Logseq is my favorite piece of software I’ve ever used. I’m glad I don’t have to manage the fork of the code myself, but I would have if I’d had to.
I’d treat the backup as the non-negotiable step. If OG opens the same markdown files cleanly, I’d test the move on a duplicate vault first and keep the original untouched until it feels boring.
