Thanks a lot for your work on this package, I am impatient of trying the roam-v2 update when it’s published.
However, I am a bit concerned by what seems to be the update plan: it looks like the plan is is to make it opt-out, by requiring that users who do not want to update switch to a different repository.
Is this path set in stone? And what is the rationale?
My concern is that it will cause unreasonable difficulties to those users who do not follow reddit/discourse/etc, and who will suddenly find their notes unusable when updating their packages.
So what is the advantage, compared to moving the roam-v2 package to a separate repository, encouraging users to switch to it, and freezing the old roam repository?
The reason lies in only keeping actively maintained packages in MELPA. With v2, v1 is orphaned and should be removed. So either way, they will have to find a way build the package from the old source code.
The plan is not ideal, but it also requires the least change from external parties (no change from MELPA etc.)
I personally don’t think that the policies of a software repository should constrain the update path of packages, especially if that leads to a wildly sub-optimal experience.
For what it’s worth, I can see a few alternative options:
ditch Melpa: keep roam-v1 there for a while, with stronger and stronger deprecation warnings, and encourage users to install v2 from git, or even switch to something like straight
convince Melpa to keep v1 and v2 simultaneously: that might be a lost cause, I saw the discussion on the Melpa issues tracker. The major blocking point seems to be that it would require 4 quasi-orphaned packages (quasi because there too, there would be sporadic change to make the deprecation more insistent).
same, but first package roam and the dependent packages together, at least for v1: then Melpa would only have one “archive” package, not 4. That of course depends on the maintainers of those other packages.
keep both v1 and v2 in the package, and have a variable decide at runtime which version to run: it doesn’t have to be fancy refactoring since v1 would not need to be maintained, it could simply be keeping the source tree of v1 in a separate subdirectory, and loading one source tree or the other depending on the value of a variable.
The last two also have the advantage of not requiring synchronization between the merges of v2 in roam and its dependent packages.
In any case, it’s sad to see this great project in such an unfortunate situation, I hope the storm won’t be too bad!
Hey! I just came here because inserting a daily note suddenly has stopped working with the error message Template needs to specify ‘:if-new’. Am I right in assuming that I’m now suddenly running V2 in stead of V1? Aargh I wanted to migrate but didn’t have the time for it yet, and now it’s happened in the middle of a workday when I ran a casual list-packagesU.
When trying M-x org-roam-find-file I get EmacSQL had an unhandled condition: "no such table: titles".
I now see that there’s a message if I don’t start emacs as a daemon but just as a new entry. But the message doesn’t point me to a good migration guide. But I guess the manual is up to date.
The manual should be up-to-date and is constantly improved by the community based on our own lessons learned. In addition, the warning message points you to the wiki
You also might like to consider running the migration script, or manually revert to V1 until you have more time.
Notes taken in v1 are incompatible with v1, but you can upgrade
them to the v2 format via a simple command. To migrate your
notes, run:
M-x org-roam-migrate-wizard
If you wish to stay on v1, v1 is unfortunately not distributed on
MELPA. See org-roam/org-roam-v1 on GitHub on how to install v1.
Yeah after finding that page it was quite easy. It was just that running emacs as a daemon didn’t show me the updated package warning, and I kind of panicked ;-). Spent the last hour figuring it out, and at least I can find my old notes and dailies now.
Seems like I need to mess with my capture templates a bit more, as I’m getting an error org-roam-capture--get-point: Wrong type argument: integer-or-marker-p, nil in stead of a capture, but we’ll see how I fix that later.
EDIT: solved, had a parenthesis issue in the capture template. Cheers for chiming in @nobiot!
.