-
|
In this thread on the google groups Saq explained that contributions towards keeping the release notes up to date are welcome.
What are the current conventions around updating the release notes? Is there a workflow? Is it preferable if the person who made the change themself updates the release notes, or can others chip in and add some merged pull requests to the release notes list? I wouldn't mind helping out with this, but I am not sure what the process entails. For example: this pull request got merged. To add this to the release notes, one would summerise the PR and add a line to the release notes tiddler? Like this:
Would in this case every PR be a line in the release notes? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 8 replies
-
|
I believe contributions are welcome. The tricky part is figuring out the last commit for which the release notes were updated and working forwards from there systematically through the commit history, so that all changes are reflected in the release notes. We could save the hash for the last update in the release notes each time to make it easier for contributors. Every commit usually leads to a line in the release notes. Multiple related commits can sometimes be combined in one line with links to each commit. Looking at the release notes for 5.1.23 would help. |
Beta Was this translation helpful? Give feedback.
-
|
In this overview, it seems that the release notes were last updated on April 04. Using the same overview of changes, I could go by them and add them to the release notes. |
Beta Was this translation helpful? Give feedback.
-
|
That sounds right. Perhaps wait to hear from @Jermolene before you put any work into this though. Thank you for your interest and willingness to contribute! |
Beta Was this translation helpful? Give feedback.
-
|
Will do! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @OdinJorna @saqimtiaz - that is pretty much it from a technical perspective; the important thing is that the release notes should be written from a users perspective, and wherever possible include a direct link to the docs to find out more. I am interested in the idea of moving the individual release note items into separate individual tiddlers so that we can structure them more richly (multiple tags etc) and display them more interactively (search, and viewing by tag). Whether or not we do that, we might also start to require that the release note update be included in the original PR. In many cases that will require a bit more dialogue, as the contributors might not always be confident about writing the release note. |
Beta Was this translation helpful? Give feedback.
-
Is this something you would like to have for the release notes of 5.1.24? I am guessing each line would be tagged by its type, for example: 'fixed', 'improved', 'added' etc., and by what is now the title. For example 'Performance Improvements'. |
Beta Was this translation helpful? Give feedback.
-
|
I would like to have the release notes in 1 tiddler. 1 tiddler for 1 line imo is overkill for a page the should be used as a landing page. I wouldn't be very comfortable, if release 1 line tddlers would spam tiddlywiki.com Just my thoughts as a user. |
Beta Was this translation helpful? Give feedback.
-
Yes, exactly that. As @pmario points out, splitting the release note might be inconvenient for some use cases, but I'd like to understand what they are. |
Beta Was this translation helpful? Give feedback.
-
Is your concern that there would be a lot of tiddlers in the timeline? That's certainly a consideration. |
Beta Was this translation helpful? Give feedback.
-
i think this is the most important part at all specially in the docs |
Beta Was this translation helpful? Give feedback.
Thanks @OdinJorna @saqimtiaz - that is pretty much it from a technical perspective; the important thing is that the release notes should be written from a users perspective, and wherever possible include a direct link to the docs to find out more.
I am interested in the idea of moving the individual release note items into separate individual tiddlers so that we can structure them more richly (multiple tags etc) and display them more interactively (search, and viewing by tag).
Whether or not we do that, we might also start to require that the release note update be included in the original PR. In many cases that will require a bit more dialogue, as the contributors might not always be con…