-
-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preparing to release 4.0.0 #113
Comments
Thank you for maintaining MELPA, magit, and other things. I have understood your point described in this thread.
Now that the snapshot version of For example, Emacs 29 will choose I am working on an alternative package manager for Emacs, so I would like to know how the package is supposed to be built and distributed to its users. |
Unfortunately there's no such mechanism. So
But that is acceptable.
A gnu/linux or bsd distribution should probably only include the I don't know where your package manager falls on that spectrum, but my guess is that it would be best (and certainly simplest) to just install |
Is it fine to even eliminate My package manager can be as flexible as the user wants it to be, because it allows working around using Nix, which is a turing complete language. |
It is fine if you know that no Emacs 29 user will ever go back to 28. Does your package manager have a "I am switching Emacs version, recompile all installed packages using the one I am switching to" command, and users are aware that they must always run that when switching? I (and every other author of an emacs package) sometimes have to switch to old Emacs releases because users insist on sticking to those and occasionally report issues that are not present when using the latest Emacs release. Right now it would be no problem if
What library? |
My package manager rebuilds all Emacs Lisp packages every time the user updates Emacs. The artifacts are stored in a centralized Nix store, so multiple versions can exist simultaneously. Byte/native-compiling can be turned off, if the user wants to.
I am talking about
Yes, it's probably |
Sounds like I might have to do another round of testing. I probably won't do that today.
Err, I have to ask again what "it" refers too. Sounds like you are asking whether In any case, I don't think EmacSQL can remove parts of itself (how would that even work)--you would have to do that in the nix package build steps. |
Sorry for this. I meant extending my package manager. |
@tarsius I just updated the paimon.el package to use the latest snapshot versions of closql and emacsql. |
Thanks! |
Note to self: don't forget to update the documentation before release.
|
/cc @Titan-C @contrapunctus @cireu @jethrokuan @r0man @md11235 @manateelazycat @hyatt
I plan to release EmacSQL 4.0.0 toward the end of the month.
The big new feature is the addition of two new SQLite backends.
emacsql-sqlite-builtin
uses the built-in support in upcoming Emacs 29, provided that wasn't disabled when configuring the build. As a fallback, the newemacsql-sqlite-module
can be used when Emacs was built with support for modules. It uses the module provided by thesqlite3
package.These backends should be preferred over the existing
emacsql-sqlite
backend, which uses a custom binary, which is slower and more prone to failure. But it is a good final fallback and I don't intend to remove it any time soon, though eventually I probably will.Users should not have to worry about which backend they use, which makes it necessary that packages are modified lightly. In most cases this should be as simple as:
If you already have added an option to allow users to pick a backend, you should remove that to ensure that the best backend is used.
emacsql-sqlite-default-connection
is used to determine that.The other big change is that going forward all backends are distributed with the
emacsql
package itself. If we didn't do that, then all packages that want users to use the best available SQLite backend would have to depend onemacsql
,emacsql-sqlite
,emacsql-sqlite-module
andemacsql-sqlite-builtin
, which would be silly. (See melpa/melpa@4872ef0 for why we include all backends.)The
emacsql
packages on Melpa and NonGNU-devel Elpa started to include all libraries a little while ago, but for the time being the backends continue to also be available as separate packages. That's not a good situation, but in this transitional phase it is necessary to prevent packages that depend onemacsql-sqlite
from breaking. That being said, we should complete the transition as soon as possible.So please update the dependencies, like so now:
That is, drop the dependency on
emacsql-sqlite
and temporarily depend on the Melpa snapshot version ofemacsql
. Doing the latter ensures that, along with your package, users update to a version ofemacsql
that containsemacsql-sqlite
and the new backend libraries. That won't cause theemacs-sqlite
to be uninstalled and I will have to deal with that later, by displaying a warning, instructing users to do so manually.After depending on the snapshot, you also won't be able to create a new release until I have released EmacSQL 4.0.0, i.e. later this month (and of course you could create a release just before starting to depend on the snapshot). When you create the first new release after EmacSQL 4.0.0 was released, you will have to make sure to change from the snapshot version to
4.0.0
.The text was updated successfully, but these errors were encountered: