Can we get releases?

Question

Can we get releases?

Closed this issue 5 years ago · 13 comments

bexelbie commented 5 years ago

I am packing multi-git-status for Fedora. I was wondering if you would consider creating versioned releases?

Answer 1 · 2019-07-28T04:31:46.000Z

Absolutely. What would be most convenient for you? I'm thinking:

Add a VERSION global var:
```
  VERSION="1.0"
```
Add a --version commandline option:
```
  multi-git-status --version
  v1.0
```

Would that work for you?

Answer 2 · 2019-07-28T04:44:41.000Z

Can you take a look at commit 2e6049d? Is that satisfactory? Do you also need things such as release notes? I have no experience with Fedora packaging, only Debian / Ubuntu, but if there's anything I can do to make your life easier by including it in upstream (man page, etc), I'd be glad to do that.

Answer 3 · 2019-07-28T04:46:38.000Z

In the future I'll make releases in the same way as I do for ansible-cmdb.

Answer 4 · 2019-07-28T08:55:09.000Z

The commit looks good. I appreciate your making releases like ansible-cmdb. That is helpful and plays right into some ease of the packaging Fedora has done with forge macros :) and eases release monitoring.

I don't need Release Notes, but I wouldn't object to them. I don't know if others feel they provide more value than just reading the commit history. The rate of commits is low and releases make release monitoring easier.

Fedora encourages all packagers to suggest that upstreams add manpages. If you have one handy, lets do it. If not, I think we can survive for now :).

One question. I notice in your screenshot you call the binary multi-git-status however the code base contains mgitstatus. Is the intention to migrate the name or do you install for both?

Answer 5 · 2019-07-29T08:32:45.000Z

I think I'll skip on the release notes in that case. It's a bit of work for each release, although it could be automated I guess. Given that there probably won't be many new features in multi-git-status, it doesn't seem worth the trouble.

Fedora encourages all packagers to suggest that upstreams add manpages

I can whip something up later today or tomorrow.

the binary multi-git-status however the code base contains mgitstatus. Is the intention to migrate the name or do you install for both?

I initially named the binary and the project "multi-git-status". However, "multi-git-status" is extremely annoying to type, and auto-completion on my system brings up a whole batch of other binaries starting with "mul" before completing to multi-git-status. So I renamed the script 'mgitstatus', which is easier to type. But now there's a discrepancy between the project name and the binary name, which is annoying for discoverability after installing a package, if the package is called 'multi-git-status' and the binary is called 'mgitstatus'.

I'm not sure what the best solution is, but probably we should just symlink 'multi-git-status' to mgitstatus or the other way around.

Answer 6 · 2019-07-29T09:21:40.000Z

@fboender Maybe you can convert parts of your README to the man page?

See eg. https://www.npmjs.com/package/remark-man and also this recent Twitter thread: https://twitter.com/voxpelli/status/1155046090175131653

I also totally understand if you don't want to introduce such dependencies, just want you to be aware of the availability of such tools 🙂

Answer 7 · 2019-07-29T10:17:37.000Z

I am not sure the mgitstatus vs multi-git-status really needs to require a project rename. I think we could easily a) do nothing; b) provide a symlink; c) have the packaging provide the alternate name (at least in Fedora I am fairly certain this can work).

I lean toward a or b. I do think we need to make sure docs, etc. are consistent.

I feel like remark-man is a massively heavy dependency for manpage generation. I don't feel rushed here, so I'd like to think about alternatives. I feel like this should be easier (Narrator: Famous last words).

Answer 8 · 2019-07-31T06:27:03.000Z

I've changed all the references of 'multi-git-status' to 'mgitstatus' in the README to make things more consistent. I think I'd prefer the official project to be called "multi-git-status", but to provide everything as 'mgitstatus'. Kind of like how Apache's official name is "The Apache HTTP Server Project" but the packages are called "httpd" (they are on Fedora, right?)

I've committed a man page and its source file. See commit 86d785f The source is a Markdown file, which is converted to man/groff format using Pandoc. There's a build target 'man' in build.sla for this. But packaging shouldn't need pandoc. I'll keep the generated version in sync and committed too.

Answer 9 · 2019-07-31T07:13:56.000Z

Was there anything else left to do? If not, I'll make a final pass on the docs and such to make sure they're correct and I'll create a v1.0 release.

Answer 10 · 2019-07-31T08:08:57.000Z

I can't think of anything else at the moment. I've gotten the package landed as "multi-git-status". I can try to find out how to rename the package if you'd prefer. I can also just look into having both names work. Do you have a preference assuming either is possible?

If you want to test, it is live in Rawhide, or should be RSN (https://bodhi.fedoraproject.org/updates/FEDORA-2019-203b0bd48d). In F30 it is in testing: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c8e1c1c700 and soon to be in stable.

Answer 11 · 2019-07-31T19:36:11.000Z

Cool, thanks so much for packaging it! I'll make a v1.0 release tomorrow, if I can find the time.

Answer 12 · 2019-08-17T16:40:44.000Z

It kinda slipped my mind a little bit. I just made created a v1 github release. If there's anything else you need, please let me know!

Answer 13 · 2019-09-02T11:13:18.000Z

The artifacts in the release seem slightly oddly named. They don't have the 'v' in front of the version. Were they manually created?