Skip to content
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

Add plugin maintainer: collecting ideas #25

Closed
doublep opened this issue Oct 1, 2020 · 11 comments
Closed

Add plugin maintainer: collecting ideas #25

doublep opened this issue Oct 1, 2020 · 11 comments
Labels
enhancement New feature or request

Comments

@doublep
Copy link
Collaborator

doublep commented Oct 1, 2020

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.

@doublep doublep added the enhancement New feature or request label Oct 1, 2020
@juergenhoetzel
Copy link
Contributor

👍
I am very interested in this functionality. I often forget one of the above tasks when releasing manually 😞

@sirikid
Copy link
Contributor

sirikid commented Oct 2, 2020

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
Copy link

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
Copy link
Collaborator Author

doublep commented Oct 5, 2020

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
Copy link

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
Copy link

bbatsov commented Oct 6, 2020

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
Copy link

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
Copy link
Collaborator Author

doublep commented Oct 24, 2020

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
Copy link
Collaborator Author

doublep commented Dec 12, 2020

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
Copy link
Collaborator Author

doublep commented Aug 14, 2022

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
Copy link
Collaborator Author

doublep commented Aug 17, 2022

Released in Eldev 1.2.

@doublep doublep closed this as completed Aug 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants