resurrecting-open-source-projects/dcfldd

Release 1.9.2 needed?

hartwork opened this issue · 7 comments

hartwork commented

Hi!

Given the time that that has passed since release 1.9.1, the commits since then and their criticality, release 1.9.2 may seem overdue. Are there plans for cutting a release 1.9.2 some time soon?

Thanks and best, Sebastian

davidpolverari commented

Hi!

Yes, you're right. I was trying to revamp the release scripts to automate the release process before releasing 1.9.2, but got caught up in a lot of work stuff and forgot about it. Thanks for the nudge, I will make a release as soon as I can.

  • 👍1
hartwork commented

Thanks!

By release scripts are you referring to https://github.com/resurrecting-open-source-projects/dcfldd/blob/master/.github/workflows/release-tarball.yml ?

Btw would you welcome a contribution of CI using man/create-man.sh to enforce keeping the rendered man page and its source in sync? I have something like that for myself in multiple places, e.g. at https://github.com/git-big-picture/git-big-picture/blob/main/.github/workflows/enforce-copies-of-help-output-in-sync.yml .

davidpolverari commented

By release scripts are you referring to https://github.com/resurrecting-open-source-projects/dcfldd/blob/master/.github/workflows/release-tarball.yml ?

No. Although this is one part of it (something I included to release the distcheck tarball when commiting a tagged release), what I mean is something like you can find on https://github.com/davidpolverari/dcfldd/blob/readme/release.sh, although it is not complete yet. I would like to remove as many manual steps as I can from the release process. I also drafted a tentative doc/RELEASE.md document (really a mix of documents ATM). I also gave a though about standardizing the commit messages to help determining the version numbering increase automatically (by using tags as "feat", "fix", etc), but I'm not still sure it would be a good idea.

In the end, I think nothing is production-ready yet (that's why I keep it on my personal fork), and I will have to release the same way yet.

Btw would you welcome a contribution of CI using man/create-man.sh to enforce keeping the rendered man page and its source in sync? I have something like that for myself in multiple places, e.g. at https://github.com/git-big-picture/git-big-picture/blob/main/.github/workflows/enforce-copies-of-help-output-in-sync.yml .

Well, I didn't quite get what you mean by that. Would it verify whether the resulting man page comes from the respective .txt file?

hartwork commented

By release scripts are you referring to https://github.com/resurrecting-open-source-projects/dcfldd/blob/master/.github/workflows/release-tarball.yml ?

No. Although this is one part of it (something I included to release the distcheck tarball when commiting a tagged release), what I mean is something like you can find on https://github.com/davidpolverari/dcfldd/blob/readme/release.sh, although it is not complete yet. I would like to remove as many manual steps as I can from the release process. I also drafted a tentative doc/RELEASE.md document (really a mix of documents ATM). I also gave a though about standardizing the commit messages to help determining the version numbering increase automatically (by using tags as "feat", "fix", etc), but I'm not still sure it would be a good idea.

In the end, I think nothing is production-ready yet (that's why I keep it on my personal fork), and I will have to release the same way yet.

@davidpolverari I see!

Btw would you welcome a contribution of CI using man/create-man.sh to enforce keeping the rendered man page and its source in sync? I have something like that for myself in multiple places, e.g. at https://github.com/git-big-picture/git-big-picture/blob/main/.github/workflows/enforce-copies-of-help-output-in-sync.yml .

Well, I didn't quite get what you mean by that. Would it verify whether the resulting man page comes from the respective .txt file?

Exactly! It would call create-man.sh to re-render the man page and then use git diff --exit-code to fail CI whenever the resulting man page no longer matches the man page file in Git.

davidpolverari commented

Exactly! It would call create-man.sh to re-render the man page and then use git diff --exit-code to fail CI whenever the resulting man page no longer matches the man page file in Git.

It would be a nice check. You can go ahead if you want.

hartwork commented

@davidpolverari awesome, change log looks great, thank you!

PS: It's already available to users of Gentoo, I just added it: gentoo/gentoo@2d9d924