Hey all, I've been committing some of your fine fixes, and at some point in the future, we will hopefully make new releases. Which got me thinking: Should I pay closer attention to keeping a changelog? Surely, when it's time for a new release Somday Soon™, I can just look back through the commit history and use GitHub to compare the current codebase to the 1.3.2 release label, right? Is that enough, or should we be taking notes on the side or something? Cheers :) Michael
Definitely, I totally forgot to do this here in my PRs! Can we (for now implicitly) stick to the policy the merge PRs only with extensions of the CHANGES file under a https://github.com/bit-team/backintime/blob/master/CHANGES If 3rd-parties contribute we could update the CHANGES ourselves after merging the PR. After each "release" the VERSION file must be increased and the CHANGELOG file updated: - Subsume noted changes for the released version. - Add new version number with hint "work in progress"
Sounds like a good plan. I'll get the CHANGES file up to speed with the changes committed so far since the 1.3.2 release. Michael On 08.09.2022 22:08, python@altfeld-im.de wrote:
Definitely, I totally forgot to do this here in my PRs!
Can we (for now implicitly) stick to the policy the merge PRs only with extensions of the CHANGES file under a
https://github.com/bit-team/backintime/blob/master/CHANGES
If 3rd-parties contribute we could update the CHANGES ourselves after merging the PR.
After each "release" the VERSION file must be increased and the CHANGELOG file updated: - Subsume noted changes for the released version. - Add new version number with hint "work in progress" _______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: foss@michael-bueker.de
On 2022-09-08 20:08 python@altfeld-im.de wrote:
After each "release" the VERSION file must be increased and the CHANGELOG file updated:
Just as a note: There is a script somewhere in the repo that do some automatics in that context. But I am not sure if this fits to all cases.
For a start, I'm currently preprating manual entries to CHANGES for everything that's happened since 1.3.2. If you find that script, let me know :) Michael On 09.09.2022 22:27, c.buhtz@posteo.jp wrote:
On 2022-09-08 20:08 python@altfeld-im.de wrote:
After each "release" the VERSION file must be increased and the CHANGELOG file updated:
Just as a note: There is a script somewhere in the repo that do some automatics in that context. But I am not sure if this fits to all cases. _______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: foss@michael-bueker.de
On 2022-09-09 22:45 Michael Büker <foss@michael-bueker.de> wrote:
If you find that script, let me know :)
I think I meant this https://github.com/bit-team/backintime/blob/master/updateversion.sh
I have a proposal regarding versioning, changelog and commits we do to the repo. For versioning, I propose Semantic Versioning[0] (BiT might be already using this). It provides a well-defined way, complete with support for intermediate/WIP releases. BiT’s versioning already fits this, and we can do things like 1.4.4beta1 to denote things are not pretty stable yet. On the commit side, I find Conventional Commits[1] useful. It requires some mental adjustment, but it also forces good development practices by dividing big commits and limiting one fix per commit. This brings commit granularity, transparency and discipline. I apply it to my own projects, and I like it. On the Changelog side, we can use a tool like Git Cliff[2], which creates changelogs from git commits automatically. I didn’t have a chance to use it, but it provides a GitHub action, so we can use this at infrastructure level, automatically. Implementing these ways and adding such discipline may reduce our load in the long term, and make project more sustainable IMHO. We can codify this into a CONTRIBUTING.md file. Moreover, even if we use Git-cliff via GH, it can be deployed independently, so we’re not tied to GitHub in the longer run. Of course, as always, comments are very welcome, Hope these ideas makes sense, Cheers, H. [0]: https://semver.org [1]: https://www.conventionalcommits.org/en/v1.0.0/ [2]: https://github.com/orhun/git-cliff
On 9 Sep 2022, at 23:50, (by way of c.buhtz@posteo.jp) <buhtz@posteo.de> wrote:
On 2022-09-09 22:45 Michael Büker <foss@michael-bueker.de> wrote:
If you find that script, let me know :)
I think I meant this https://github.com/bit-team/backintime/blob/master/updateversion.sh _______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: hakan@bayindir.org
On Sun, 2022-09-11 at 14:09 +0300, Hakan Bayındır wrote:
For versioning, I propose Semantic Versioning[0] (BiT might be already using this). [...] BiT’s versioning already fits this, and we can do things like 1.4.4beta1 to denote things are not pretty stable yet.
Semantic versioning is OK and as user I'd like to see also the release date in the version number to get a feeling how old the tool is that I am using. Could we add the release date to the CHANGE(LOG) file at least?
On the commit side, I find Conventional Commits[1] useful. It requires some mental adjustment, but it also forces good development practices by dividing big commits and limiting one fix per commit. This brings commit granularity, transparency and discipline. I apply it to my own projects, and I like it. [...] On the Changelog side, we can use a tool like Git Cliff[2], which creates changelogs from git commits automatically.
Excellent proposal, esp. together with Cliff BTW: I really love to learn best practices from others - that motivates me to contribute to project ;-)
Implementing these ways and adding such discipline may reduce our load in the long term, and make project more sustainable IMHO. We can codify this into a CONTRIBUTING.md file.
Good point, where can we add this TODO? We could also add the recommendation of "git rebase" or "merge --squash" to "compress" multiple (intermediate) commits into one feature/fix/... commit for a clean history that can be processes by Cliff...
On 11 Sep 2022, at 15:11, J. A. <python@altfeld-im.de> wrote:
On Sun, 2022-09-11 at 14:09 +0300, Hakan Bayındır wrote:
For versioning, I propose Semantic Versioning[0] (BiT might be already using this). [...] BiT’s versioning already fits this, and we can do things like 1.4.4beta1 to denote things are not pretty stable yet.
Semantic versioning is OK and as user I'd like to see also the release date in the version number to get a feeling how old the tool is that I am using.
Could we add the release date to the CHANGE(LOG) file at least?
I personally add dates to my own CHANGELOG files, and will certainly support this idea.
On the commit side, I find Conventional Commits[1] useful. It requires some mental adjustment, but it also forces good development practices by dividing big commits and limiting one fix per commit. This brings commit granularity, transparency and discipline. I apply it to my own projects, and I like it. [...] On the Changelog side, we can use a tool like Git Cliff[2], which creates changelogs from git commits automatically.
Excellent proposal, esp. together with Cliff
BTW: I really love to learn best practices from others - that motivates me to contribute to project ;-)
Same for me!
Implementing these ways and adding such discipline may reduce our load in the long term, and make project more sustainable IMHO. We can codify this into a CONTRIBUTING.md file.
Good point, where can we add this TODO?
Maybe we can use the issue tracker to open these kinds of tickets, too. Any other ideas?
We could also add the recommendation of "git rebase" or "merge --squash" to "compress" multiple (intermediate) commits into one feature/fix/... commit for a clean history that can be processes by Cliff...
I have no strong opinions and much experience in that kind of git management. We can discuss and agree on something, then codify it too. All in all, my aim is to make project much more stable and sustainable from a management standpoint going forward. Cheers, H.
_______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: hakan@bayindir.org
Hello, I also support and vote for semantic versioning (which is still there) and conventional commits. I don't know Cliff. Because the CHANGELOG is very important I won't like to have a full automatic at this point. Tools collecting the commits and create a draft(!) of a CHANGELOG out of it which can be checked and corrected by a human being maintainer would be nice. But I would simply copy and paste a "git log" output and edit that. Oh yeah, release dates would be great. I often miss them in other projects. I'm quit experienced in git and git project management. The "problem" about multiple commit messages in a PR is not a "problem". Michael as the merger can squash them in the GitHub web front-end. How to handle git branches etc is up to the maintainers with commit/merge rights and not a problem of a usual contributor opening a PR. IMHO it is the responsibility of the merging maintainer to commit a PR with a "good" commit message in a "good" branch. The topic keyword here is "git branching models" (sometimes synonym used "git workflow"). This topic is to early and will come up, when Germar decided about the handover of rights. Kind Christian
Hi all, On 11.09.2022 14:11, J. A. wrote:
Semantic versioning is OK and as user I'd like to see also the release date in the version number to get a feeling how old the tool is that I am using.
Could we add the release date to the CHANGE(LOG) file at least?
That's a good idea. I will research the release dates for the last few releases (going back to 1.2.0 or so) and add them to the CHANGES file.
Implementing these ways and adding such discipline may reduce our load in the long term, and make project more sustainable IMHO. We can codify this into a CONTRIBUTING.md file.
Good point, where can we add this TODO?
You can open an Issue, and I will tag it with "Infrastructure" and/or "Meta" to show that's about our workflow (instead of a bug or feature discussion). Cheers :) Michael
I've gathered together what I found by looking at https://github.com/bit-team/backintime/compare/v1.3.2...master and put it into a PR for the CHANGES file: https://github.com/bit-team/backintime/pull/1289 Kindly check it out to see if it looks okay :) Michael On 08.09.2022 21:42, Michael Büker wrote:
Hey all,
I've been committing some of your fine fixes, and at some point in the future, we will hopefully make new releases. Which got me thinking: Should I pay closer attention to keeping a changelog?
Surely, when it's time for a new release Somday Soon™, I can just look back through the commit history and use GitHub to compare the current codebase to the 1.3.2 release label, right?
Is that enough, or should we be taking notes on the side or something?
Cheers :) Michael _______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: foss@michael-bueker.de
Kindly check it out to see if it looks okay :)
Thanks for this hard work that requires great diligence CHANGELOG looks good so, I have browsed the commits to compare it. Only one question arised to me: Shall the CHANGELOG document the changes a) of BiT as App b) or of the repo I would assume the each release of the BiT App contains a changelog so I'd prefer the first interpretation a). This means that changes of the README (like "add section with known problems" https://github.com/bit-team/backintime/commit/abf7d09d71dd5da803765c8962b8d5...) or "add code coverage as make target" are not contained in the CHANGELOG since it may IMHO not directly be relevant for the users of BiT. (Different) opinions welcome :-)
On 2022-09-11 13:19 "J. A." <python@altfeld-im.de> wrote:
Only one question arised to me:
Shall the CHANGELOG document the changes a) of BiT as App b) or of the repo
Damn! We on a quit high level here! :D I learn so much. ;) I have no opinion about that question. But it reminds me on some nerdy IT podcast I was listing to a discussion between two "professional" (payed) developers arguing about the difference between commit messages and changelog entries. I can't remember or didn't understand a solution on that discussion. But I would say that a) is something that could be described from the perspective of a user; a "user story". e.g. "BIT now can use rsync versions 3.2.4 and higher" And b) is more developer/technical; e.g. "Use '-s' rsync-switch to activate the modern and recommended way of argument protection in all rsync versions starting with 2.4 and higher". I do not have a final opinion about that. If anyone does more research on that and find articles about it please let me know.
Dear all, this is my first post here, so: Hello to everyone. (I will decide in the next weeks if I can help you with this project. So far, this is just an initial contact.) I'ld recommend a changelog for the app that is distributed with new releases. This is a short summary for the end user in my opinion. Of course, a date for each release does not hurt, too. ;) The repository related changes are changes to the development mode in my opinion. Either one is defining some kind of code of conduct / coding guidelines in another document, a wiki or somewhere else or it is a proven process forced by the active developers (and resulting in code documentation all over the project). I wouldn't try to mix that in a single "changelog" file. Best, Lutz
c.buhtz@posteo.jp hat am 11.09.2022 15:53 CEST geschrieben:
On 2022-09-11 13:19 "J. A." <python@altfeld-im.de> wrote:
Only one question arised to me:
Shall the CHANGELOG document the changes a) of BiT as App b) or of the repo
Damn! We on a quit high level here! :D I learn so much. ;)
I have no opinion about that question. But it reminds me on some nerdy IT podcast I was listing to a discussion between two "professional" (payed) developers arguing about the difference between commit messages and changelog entries.
I can't remember or didn't understand a solution on that discussion.
But I would say that a) is something that could be described from the perspective of a user; a "user story". e.g. "BIT now can use rsync versions 3.2.4 and higher" And b) is more developer/technical; e.g. "Use '-s' rsync-switch to activate the modern and recommended way of argument protection in all rsync versions starting with 2.4 and higher".
I do not have a final opinion about that. If anyone does more research on that and find articles about it please let me know. _______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: lutzl@mailbox.org
On Sun, 2022-09-11 at 17:15 +0200, lutzl--- via Bit-dev wrote:
this is my first post here, so: Hello to everyone. (I will decide in the next weeks if I can help you with this project. So far, this is just an initial contact.)
so welcome is this newly forming team, any support is welcome and needed (nothing is too small ;-)
Welcome to the list, and hopefully to the team :) We're all new here, so take a look around and see how you might like to help. Cheers, Michael On 11.09.2022 17:15, lutzl--- via Bit-dev wrote:
Dear all,
this is my first post here, so: Hello to everyone. (I will decide in the next weeks if I can help you with this project. So far, this is just an initial contact.)
I'ld recommend a changelog for the app that is distributed with new releases. This is a short summary for the end user in my opinion. Of course, a date for each release does not hurt, too. ;)
The repository related changes are changes to the development mode in my opinion. Either one is defining some kind of code of conduct / coding guidelines in another document, a wiki or somewhere else or it is a proven process forced by the active developers (and resulting in code documentation all over the project). I wouldn't try to mix that in a single "changelog" file.
Best, Lutz
c.buhtz@posteo.jp hat am 11.09.2022 15:53 CEST geschrieben:
On 2022-09-11 13:19 "J. A." <python@altfeld-im.de> wrote:
Only one question arised to me:
Shall the CHANGELOG document the changes a) of BiT as App b) or of the repo
Damn! We on a quit high level here! :D I learn so much. ;)
I have no opinion about that question. But it reminds me on some nerdy IT podcast I was listing to a discussion between two "professional" (payed) developers arguing about the difference between commit messages and changelog entries.
I can't remember or didn't understand a solution on that discussion.
But I would say that a) is something that could be described from the perspective of a user; a "user story". e.g. "BIT now can use rsync versions 3.2.4 and higher" And b) is more developer/technical; e.g. "Use '-s' rsync-switch to activate the modern and recommended way of argument protection in all rsync versions starting with 2.4 and higher".
I do not have a final opinion about that. If anyone does more research on that and find articles about it please let me know. _______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: lutzl@mailbox.org
Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: foss@michael-bueker.de
Hi, all! On 11.09.2022 13:19, J. A. wrote:
Kindly check it out to see if it looks okay :)
Thanks for this hard work that requires great diligence
CHANGELOG looks good so, I have browsed the commits to compare it.
Perfect, thanks for the effort :) I like to do this sort of "administrative" work that's mostly in the background. Other are much better at coding ;)
Only one question arised to me:
Shall the CHANGELOG document the changes a) of BiT as App b) or of the repo
I would assume the each release of the BiT App contains a changelog so I'd prefer the first interpretation a).
Yes, I agree. I was composing the CHANGES file to be read by users who want to know "What's changed?". That's why I left out changes to README.md, and only very briefly mentioned changes to our testing infrastructure (Travis etc.). Cheers, Michael
participants (7)
-
buhtz＠posteo.de -
c.buhtz＠posteo.jp -
Hakan Bayındır -
J. A. -
lutzl＠mailbox.org -
Michael Büker -
python＠altfeld-im.de