Closed doublep closed 2 years ago
:+1: I am very interested in this functionality. I often forget one of the above tasks when releasing manually :disappointed:
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.
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.
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.
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.
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:
It might also be useful to have a command checking whether all of your package's deps are up-to-date.
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.
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?
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...
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:
update-copyright
is not implemented yet.Released in Eldev 1.2.
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 theirEldev-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:
.el
file;Command: update-copyright [FILES]
Update copyright notices in given files (default: all files that have them in all filesets), commit, maybe push.