Add plugin `maintainer`: collecting ideas

doublep commented 3 years ago

I'm creating an issue for this instead of just implementing it, since I would like to see comments from people who use Eldev in this case. If it is at all useful for you or how you would change this.

@sirikid, @DarwinAwardWinner, @tsuu32, @LaurenceWarne, @bbatsov, @lordpretzel, @mithrandi, @juergenhoetzel, @DamienCassou: According to GitHub search you are using Eldev in one more of your project. Sorry to bother you, but if you are interested in proposed functionality, maybe you could leave some comment? Just unsubscribe from this thread if you are not interested to avoid further notification spam.

Current ideas

Reasons for this being a plugin rather than standard functionality: usually only one or a few people have permissions to maintain (for now, read: create releases) of a project. It is expected that the plugin is activated in Eldev-local. However, a project is free to activate it for everyone, of course (but it might be confusing for people who cannot use the plugin, yet see its command(s)).

Plugin's configuration can be changed without activating it (automatically so: global Elisp variables work this way). This means a project can tweak some settings in its Eldev even without activating the plugin, i.e. leaving this for relevant people to do in their Eldev-local. However, you cannot access configuration (in order to e.g. tweak a value instead of replacing it completely) without requiring the plugin.

Command: release VERSION

Create new release of the project:

validate the version (at least must be newer than the current);
optionally run tests or check some CI output and stop if there are fails;
create VCS (probably only Git for now) commit (comment tweakable) with altered version in relevant .el file;
create tag (format of tag name tweakable);
optionally create post-release version bump commit;
push everything (can be disabled so that you can preview what it does and push yourself if you are satisfied).

Command: update-copyright [FILES]

Update copyright notices in given files (default: all files that have them in all filesets), commit, maybe push.

juergenhoetzel commented 3 years ago

:+1: I am very interested in this functionality. I often forget one of the above tasks when releasing manually :disappointed:

sirikid commented 3 years ago

I absolutely love this idea, Elisp deserves good tools.

create VCS (probably only Git for now) commit (comment tweakable) with altered version in relevant .el file;

create tag (format of tag name tweakable);

optionally create post-release version bump commit;

push everything (can be disabled so that you can preview what it does and push yourself if you are satisfied).

You can use VC or Magit for this. If you choose Magit, I think you can implement this part as a Magit plugin.

DamienCassou commented 3 years ago

I don't think this feature has anything to do with Emacs Lisp: the actions you mention seem to be the same for any project in any language. This makes me think that there are probably dedicated tools to do the same, probably better.

doublep commented 3 years ago

I don't think this feature has anything to do with Emacs Lisp: the actions you mention seem to be the same for any project in any language.

Mostly yes, though some things with the version are somewhat Elisp-specific: it has to be understandable by Emacs and it needs to be put in the correct place in a .el file.

This makes me think that there are probably dedicated tools to do the same, probably better.

Word "probably" suggests you don't know any, probably because you are not interested in this functionality at all — whether from Eldev or some other tool. I have also seen some custom-grown Python and Shell scripts to automate release process in a few projects (not necessarily Elisp ones) and I'm sure yet some others use Makefile targets.

Anyway, I'm generally not a fan of having a hundred tools for a hundred of tasks. I rather like IDE or, hm, Emacs model that binds a lot of tools together — or writes them as needed.

DarwinAwardWinner commented 3 years ago

Yes, I would be interested in this. Currently I have an ad-hoc script to do the version number incrementation semi-automatically: https://github.com/DarwinAwardWinner/ido-completing-read-plus/blob/master/setversion.sh

I would be happy if Eldev made that script obsolete. Although that sounds slightly outside the scope of what you're currently proposing.

bbatsov commented 3 years ago

I'd be interested in something like this as well, as I'm using such plugins for my Ruby and Clojure projects. Other tasks that you typically need to do on release would include:

Updating the changelog
Updating version references in the README docs
Updating the changelog
You might also have to set some version metadata in the docs (if you're building multiple versions of it for each release branch)

It might also be useful to have a command checking whether all of your package's deps are up-to-date.

DamienCassou commented 3 years ago

Word "probably" suggests you don't know any, probably because you are not interested in this functionality at all

You are completely right: I don't know any and I'm not interested :-). A quick search reveals https://www.npmjs.com/package/semantic-release though.

doublep commented 3 years ago

A quick search reveals https://www.npmjs.com/package/semantic-release though.

With this particular tool I'd have a problem in that it strongly binds to commit messages.

What I rather have in mind is something like release-it. It seems JS-oriented, but more or less works also for other types of projects.

To everyone that have expressed interest: do you think Eldev should grow something similar, try to build a plugin that reuses this (or a similar) tool, or just not bother as good alternatives exist?

doublep commented 3 years ago

Probably giving up on this. Apparently there is no way in crappy Elisp to forward stdout/stderr from a child process, which makes running child processes that take non-trivial amount of time a pain from usability point of view (you don't see the output as it is being produced). Maybe something could be hacked with a Python wrapper on top of Eldev, but meh...

doublep commented 2 years ago

I have decided to resurrect these ideas. Will be release soon (maybe tomorrow) in Eldev 1.2. Documentation is here: https://github.com/doublep/eldev/tree/future-doc#maintainer-plugin

The major problem is that Elisp doesn't really allow proper stdout/stderr forwarding from child processes. I have decided that it is not that important. As a workaround eldev-call-process forwards both streams to Eldev's stdout. Oh well.

Compared to the initial post:

CI-servers are not checked automatically, you need to "know what you are doing";
never pushes — just do this manually (so you can first rebase, reword etc. commits if you want);
minor quality-of-life feature: add word "DONOTRELEASE" anywhere in your source code to have Eldev remind you about this whenever you make a release (intended use: add in comments before things you don't want to fix now but need to fix before making a release);
command update-copyright is not implemented yet.

doublep commented 2 years ago

Released in Eldev 1.2.

emacs-eldev / eldev