search

resurrecting-open-source-projects / dcfldd

Enhanced version of dd for forensics and security
GNU General Public License v2.0
91 stars 20 forks source link

Release 1.9.2 needed? #35

Open hartwork opened 1 week ago

hartwork commented 1 week ago

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 1 week ago

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.

hartwork commented 6 days ago

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 5 days ago

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 2 days ago

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.