home.social

#towncrier — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #towncrier, aggregated by home.social.

  1. Been playing around with #towncrier for the past couple of days.
    I like its approach to creating & updating changelogs(plus its support for both .md & .rst output)

    Between its clear tutorial and referencing pipx & pytest's usage of the package, I think it's going to be an easy add-on to my projects. Plus, I really need to get better disciplined at writing regular consistent #Changelog

    towncrier.readthedocs.io/en/st

    #Python

  2. Been playing around with #towncrier for the past couple of days.
    I like its approach to creating & updating changelogs(plus its support for both .md & .rst output)

    Between its clear tutorial and referencing pipx & pytest's usage of the package, I think it's going to be an easy add-on to my projects. Plus, I really need to get better disciplined at writing regular consistent #Changelog

    towncrier.readthedocs.io/en/st

    #Python

  3. Been playing around with for the past couple of days.
    I like its approach to creating & updating changelogs(plus its support for both .md & .rst output)

    Between its clear tutorial and referencing pipx & pytest's usage of the package, I think it's going to be an easy add-on to my projects. Plus, I really need to get better disciplined at writing regular consistent

    towncrier.readthedocs.io/en/st

  4. Been playing around with #towncrier for the past couple of days.
    I like its approach to creating & updating changelogs(plus its support for both .md & .rst output)

    Between its clear tutorial and referencing pipx & pytest's usage of the package, I think it's going to be an easy add-on to my projects. Plus, I really need to get better disciplined at writing regular consistent #Changelog

    towncrier.readthedocs.io/en/st

    #Python

  5. Been playing around with #towncrier for the past couple of days.
    I like its approach to creating & updating changelogs(plus its support for both .md & .rst output)

    Between its clear tutorial and referencing pipx & pytest's usage of the package, I think it's going to be an easy add-on to my projects. Plus, I really need to get better disciplined at writing regular consistent #Changelog

    towncrier.readthedocs.io/en/st

    #Python

  6. Finally released a new version 0.5.0a0 of `sphinxcontrib-towncrier` — my #Sphinx extension for injecting future draft/unreleased bits of Towncrier-managed change logs.

    The main theme of this version is supporting Towncrier 24.7.0rc1 and higher.

    #Python #Towncrier

  7. Finally released a new version 0.5.0a0 of `sphinxcontrib-towncrier` — my #Sphinx extension for injecting future draft/unreleased bits of Towncrier-managed change logs.

    The main theme of this version is supporting Towncrier 24.7.0rc1 and higher.

    #Python #Towncrier

  8. Finally released a new version 0.5.0a0 of `sphinxcontrib-towncrier` — my #Sphinx extension for injecting future draft/unreleased bits of Towncrier-managed change logs.

    The main theme of this version is supporting Towncrier 24.7.0rc1 and higher.

    #Python #Towncrier

  9. Finally released a new version 0.5.0a0 of `sphinxcontrib-towncrier` — my #Sphinx extension for injecting future draft/unreleased bits of Towncrier-managed change logs.

    The main theme of this version is supporting Towncrier 24.7.0rc1 and higher.

    #Python #Towncrier

  10. Finally released a new version 0.5.0a0 of `sphinxcontrib-towncrier` — my #Sphinx extension for injecting future draft/unreleased bits of Towncrier-managed change logs.

    The main theme of this version is supporting Towncrier 24.7.0rc1 and higher.

    #Python #Towncrier

  11. Hoje é dia de Live de Python! \o/

    Você já se perguntou como organizar e documentar as mudanças do seu código? 🤔

    Hoje, conversaremos sobre changelogs, como eles ajudam a manter seu projeto organizado e como gerá-los facilmente com Towncrier!

    Às 22h! 🔥

    youtube.com/live/ATKJXpHrBfE

    🔁🔁🔁

    #python #towncrier #changelogs

  12. Hoje é dia de Live de Python! \o/

    Você já se perguntou como organizar e documentar as mudanças do seu código? 🤔

    Hoje, conversaremos sobre changelogs, como eles ajudam a manter seu projeto organizado e como gerá-los facilmente com Towncrier!

    Às 22h! 🔥

    youtube.com/live/ATKJXpHrBfE

    🔁🔁🔁

    #python #towncrier #changelogs

  13. Hoje é dia de Live de Python! \o/

    Você já se perguntou como organizar e documentar as mudanças do seu código? 🤔

    Hoje, conversaremos sobre changelogs, como eles ajudam a manter seu projeto organizado e como gerá-los facilmente com Towncrier!

    Às 22h! 🔥

    youtube.com/live/ATKJXpHrBfE

    🔁🔁🔁

    #python #towncrier #changelogs

  14. Hoje é dia de Live de Python! \o/

    Você já se perguntou como organizar e documentar as mudanças do seu código? 🤔

    Hoje, conversaremos sobre changelogs, como eles ajudam a manter seu projeto organizado e como gerá-los facilmente com Towncrier!

    Às 22h! 🔥

    youtube.com/live/ATKJXpHrBfE

    🔁🔁🔁

    #python #towncrier #changelogs

  15. Hoje é dia de Live de Python! \o/

    Você já se perguntou como organizar e documentar as mudanças do seu código? 🤔

    Hoje, conversaremos sobre changelogs, como eles ajudam a manter seu projeto organizado e como gerá-los facilmente com Towncrier!

    Às 22h! 🔥

    youtube.com/live/ATKJXpHrBfE

    🔁🔁🔁

    #python #towncrier #changelogs

  16. i wrote this #python #cli #tool last year it's pretty good.

    #protokolo generates a #changelog from fragment files, kind of like #towncrier, but way less intelligently (in a good way). its purpose is to circumvent the problem where many #vcs commits attempt to edit the same section in the change log file, and they #mergeConflict all the time. (or worse, a pr that is merged late adds its change log to a previous release.)

    protokolo.readthedocs.io/en/st

    #development #programming #git

  17. i wrote this #python #cli #tool last year it's pretty good.

    #protokolo generates a #changelog from fragment files, kind of like #towncrier, but way less intelligently (in a good way). its purpose is to circumvent the problem where many #vcs commits attempt to edit the same section in the change log file, and they #mergeConflict all the time. (or worse, a pr that is merged late adds its change log to a previous release.)

    protokolo.readthedocs.io/en/st

    #development #programming #git

  18. i wrote this #python #cli #tool last year it's pretty good.

    #protokolo generates a #changelog from fragment files, kind of like #towncrier, but way less intelligently (in a good way). its purpose is to circumvent the problem where many #vcs commits attempt to edit the same section in the change log file, and they #mergeConflict all the time. (or worse, a pr that is merged late adds its change log to a previous release.)

    protokolo.readthedocs.io/en/st

    #development #programming #git

  19. i wrote this #python #cli #tool last year it's pretty good.

    #protokolo generates a #changelog from fragment files, kind of like #towncrier, but way less intelligently (in a good way). its purpose is to circumvent the problem where many #vcs commits attempt to edit the same section in the change log file, and they #mergeConflict all the time. (or worse, a pr that is merged late adds its change log to a previous release.)

    protokolo.readthedocs.io/en/st

    #development #programming #git

  20. i wrote this #python #cli #tool last year it's pretty good.

    #protokolo generates a #changelog from fragment files, kind of like #towncrier, but way less intelligently (in a good way). its purpose is to circumvent the problem where many #vcs commits attempt to edit the same section in the change log file, and they #mergeConflict all the time. (or worse, a pr that is merged late adds its change log to a previous release.)

    protokolo.readthedocs.io/en/st

    #development #programming #git

  21. Practically, I find it very helpful to write the change log item as an update to the change log document, included *as separately written documentation*, one change among others included in the same merge request.

    Consider it like updating the API documentation in the same merge request that changes the API. Except here, the interface is for the humans considering whether and why to update to this version.

    And a tool like towncrier.readthedocs.io/ can help a lot.

    @xavdid @nedbat

  22. Practically, I find it very helpful to write the change log item as an update to the change log document, included *as separately written documentation*, one change among others included in the same merge request.

    Consider it like updating the API documentation in the same merge request that changes the API. Except here, the interface is for the humans considering whether and why to update to this version.

    And a tool like #TownCrier towncrier.readthedocs.io/ can help a lot.

    @xavdid @nedbat

  23. Practically, I find it very helpful to write the change log item as an update to the change log document, included *as separately written documentation*, one change among others included in the same merge request.

    Consider it like updating the API documentation in the same merge request that changes the API. Except here, the interface is for the humans considering whether and why to update to this version.

    And a tool like #TownCrier towncrier.readthedocs.io/ can help a lot.

    @xavdid @nedbat

  24. Practically, I find it very helpful to write the change log item as an update to the change log document, included *as separately written documentation*, one change among others included in the same merge request.

    Consider it like updating the API documentation in the same merge request that changes the API. Except here, the interface is for the humans considering whether and why to update to this version.

    And a tool like #TownCrier towncrier.readthedocs.io/ can help a lot.

    @xavdid @nedbat

  25. Practically, I find it very helpful to write the change log item for a merge request as an update to the change log document, included *as separately written documentation* in the merge request itself.

    Consider it like updating the API documentation in the same merge request that changes the API. Except here, the interface is for the humans considering whether and why to update to this version.

    And a tool like #TownCrier towncrier.readthedocs.io/ can help a lot.

    @xavdid @nedbat

  26. I hate merge conflicts in my change logs.

    I'm aware of #towncrier, but it's a bit finicky and prescriptive.

    Is there another general-purpose #changelog generator, or is this something I'm going to end up writing myself?

  27. I hate merge conflicts in my change logs.

    I'm aware of #towncrier, but it's a bit finicky and prescriptive.

    Is there another general-purpose #changelog generator, or is this something I'm going to end up writing myself?

  28. I hate merge conflicts in my change logs.

    I'm aware of #towncrier, but it's a bit finicky and prescriptive.

    Is there another general-purpose #changelog generator, or is this something I'm going to end up writing myself?

  29. I hate merge conflicts in my change logs.

    I'm aware of #towncrier, but it's a bit finicky and prescriptive.

    Is there another general-purpose #changelog generator, or is this something I'm going to end up writing myself?

  30. I hate merge conflicts in my change logs.

    I'm aware of #towncrier, but it's a bit finicky and prescriptive.

    Is there another general-purpose #changelog generator, or is this something I'm going to end up writing myself?

  31. I'm looking for something like #Scompler for Mastodon.

    A tool that lets you schedule posts and analyze your interactions.

    So far I've found and tried #Analytodon #Buffer #Fedilab #Fediplan #Scheduler #Seenly #Towncrier #Tweepsmap.

    I made a quick table with the results of my tests: joinfediverse.wiki/Scheduling_

    Does anybody know any other tools? Preferably something that ticks all the boxes?

  32. I'm looking for something like #Scompler for Mastodon.

    A tool that lets you schedule posts and analyze your interactions.

    So far I've found and tried #Analytodon #Buffer #Fedilab #Fediplan #Scheduler #Seenly #Towncrier #Tweepsmap.

    I made a quick table with the results of my tests: joinfediverse.wiki/Scheduling_

    Does anybody know any other tools? Preferably something that ticks all the boxes?

  33. I'm looking for something like #Scompler for Mastodon.

    A tool that lets you schedule posts and analyze your interactions.

    So far I've found and tried #Analytodon #Buffer #Fedilab #Fediplan #Scheduler #Seenly #Towncrier #Tweepsmap.

    I made a quick table with the results of my tests: joinfediverse.wiki/Scheduling_

    Does anybody know any other tools? Preferably something that ticks all the boxes?

  34. I'm looking for something like #Scompler for Mastodon.

    A tool that lets you schedule posts and analyze your interactions.

    So far I've found and tried #Analytodon #Buffer #Fedilab #Fediplan #Scheduler #Seenly #Towncrier #Tweepsmap.

    I made a quick table with the results of my tests: joinfediverse.wiki/Scheduling_

    Does anybody know any other tools? Preferably something that ticks all the boxes?

  35. I'm looking for something like #Scompler for Mastodon.

    A tool that lets you schedule posts and analyze your interactions.

    So far I've found and tried #Analytodon #Buffer #Fedilab #Fediplan #Scheduler #Seenly #Towncrier #Tweepsmap.

    I made a quick table with the results of my tests: joinfediverse.wiki/Scheduling_

    Does anybody know any other tools? Preferably something that ticks all the boxes?

  36. Agreed @webaware, it is a clear sign that the release was made with no user-facing description of the changes.

    If you don't already have the user-facing description of the change ready, it's not ready to commit to version control, and certainly not ready to release.

    I like as a way to write a summary description of each change, committed along with the code change and assembled automatically into a user-facing change log document when it's time to release.

    towncrier.readthedocs.io/

  37. Agreed @webaware, it is a clear sign that the release was made with no user-facing description of the changes.

    If you don't already have the user-facing description of the change ready, it's not ready to commit to version control, and certainly not ready to release.

    I like #TownCrier as a way to write a summary description of each change, committed along with the code change and assembled automatically into a user-facing change log document when it's time to release.

    towncrier.readthedocs.io/

  38. Agreed @webaware, it is a clear sign that the release was made with no user-facing description of the changes.

    If you don't already have the user-facing description of the change ready, it's not ready to commit to version control, and certainly not ready to release.

    I like #TownCrier as a way to write a summary description of each change, committed along with the code change and assembled automatically into a user-facing change log document when it's time to release.

    towncrier.readthedocs.io/

  39. Agreed @webaware, it is a clear sign that the release was made with no user-facing description of the changes.

    If you don't already have the user-facing description of the change ready, it's not ready to commit to version control, and certainly not ready to release.

    I like #TownCrier as a way to write a summary description of each change, committed along with the code change and assembled automatically into a user-facing change log document when it's time to release.

    towncrier.readthedocs.io/

  40. Agreed @webaware, it is a clear sign that the release was made with no user-facing description of the changes.

    If you don't already have the user-facing description of the change ready, it's not ready to commit to version control, and certainly not ready to release.

    I like #TownCrier as a way to write a summary description of each change, committed along with the code change and assembled automatically into a user-facing change log document when it's time to release.

    towncrier.readthedocs.io/