search

pekingduck / emacs-sqlite3-api

SQLite3 API for GNU Emacs 25+
GNU General Public License v3.0
62 stars 5 forks source link

Adding this package to NonGNU Elpa #7

Closed tarsius closed 1 year ago

tarsius commented 1 year ago

I am preparing for the release of emacsql 4.0.0.

This adds two new SQLite backends. The new preferred backend uses the new built-in SQLite support in Emacs 29. If that cannot be used, then the other new backend, which uses your module, should be used. Only if that isn't available either should the old backend be used, which uses a custom sqlite binary.

(Also see https://github.com/magit/emacsql/issues/113)

Since emacsql is also available from NonGNU-devel Elpa, and will be available from NonGNU Elpa once I release 4.0.0, it would be good to add this package there as well. Otherwise users that aren't yet on Emacs 29 would be stuck on the old backend, which uses the binary.

If you agree, I can take care of proposing that in emacs-devel and add the necessary metadata.

pekingduck commented 1 year ago

Please go ahead. I am OK with this. Thanks a lot!

tarsius commented 1 year ago

Richard asks (1) whether you agree to follow the rules (2).

(1) https://lists.gnu.org/archive/html/emacs-devel/2023-03/msg00142.html (2) https://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/README.org#n141

pekingduck commented 1 year ago

Ok I just checked out the links above. Don't think it's a problem. Thanks

tarsius commented 1 year ago

I've just added this to NonGNU ELPA.

One last request (hopefully); could you please create a new release? In the next EmacSQL release I would like to depend on a version of this package that includes #6. Thanks!

tarsius commented 1 year ago

One last request (hopefully);

Well... :roll_eyes:

Unfortunately the tool used to maintain [Non]GNU ELPA archives ignores vcs tags and instead expects a "Version" or "Package-Version" library header, so you have to add such a header.

I recommend using "Release version N" as the commit message after adding/bumping N in the library header, and to then tag that commit with vN. I.e., it is important to keep the two instances of the version string in sync, making sure you tag the very commit that bumped the in-tree instance of the version string.

You might also want to bump the copyright years in the elisp library.

pekingduck commented 1 year ago

Done. Version bumped to v0.17.

tarsius commented 1 year ago

Thanks!

Looks good. The package should appear on NonGNU Elpa within a few ours.