Develop consistent method for capturing release notes across all PDS repositories #25
Replies: 12 comments
-
I've seen (c) used the most. It forces teams to distill commit messages into a few bullet points, explaining at a high-level what was changed. One disadvantage of using release notes, is that it's somewhat hidden away in Github. It may make sense to update the release notes, but also to maintain a separate markdown document, linked to from the README. |
Beta Was this translation helpful? Give feedback.
-
Usually the biggest challenge in release notes that I've experienced is with content. Someone actually needs to input the data regarding the changes somewhere, whether it is in commit messages or tickets. First of all, "release notes" I've seen for Lab projects have been markdown documents at the top-level of the repository named Are there automated ways to generate the bulleted list? Yes, but there will be some level of (perhaps minimal) added developer commitment. We know about the hard way (reliance on one expert) which generates notes manually by relying on a single person creating a mini report of relevant tickets. Conversely, an automated way is to rely on the team with just a little more commit information. A Git commit hook requires ticket numbers to be inserted into any code commit message (excluding merge or release). At release time a script is run that collects commit messages, parses them for (required) ticket information and collects detail from the Jira/GitHub ticketing API. Then notes are composed using ticket titles, or perhaps the first sentence of the description, or anything in the ticketing system. Another very similar option is simply collect the first 100 chars of any commit message without querying a ticketing API for detail. |
Beta Was this translation helpful? Give feedback.
-
@jpl-jengelke my concern with commit messages is a few things:
|
Beta Was this translation helpful? Give feedback.
-
I like the suggestion of @jpl-jengelke on "A Git commit hook requires ticket numbers to be inserted into any code commit message". I have seen successful uses of this method to capture the traceability from the requirements (user stories) to implementation. I also agree with the concerns of @jordanpadams on commit messages. I think instead of the commit messages, we can pickup the high-level user stories (issues) as follows. Some suggestions:
|
Beta Was this translation helpful? Give feedback.
-
@jordanpadams wrote:
I totally get the concerns, and we spent a lot of time discussing this approach. In the end, though, it wasn't a big burden. Once a ticket number was required in commit messages, it became second nature. If a general commit was needed for something like code cleanup, devs had a generic ticket number on hand. In the end it boiled down to typing a |
Beta Was this translation helpful? Give feedback.
-
@ramesh-maddegoda @jpl-jengelke thanks for the feedback. I guess to rephrase the concern a bit, we pretty much do something like this already and our users don't find it helpful. Our changelogs are auto-generated for ever merged PR, and every PR should (and most the time does) include the issue number. if not, we are usually pretty good about going back to the issue and referencing the specific PR or commit when we close the issue. Here are some examples: https://github.com/NASA-PDS/validate/blob/main/CHANGELOG.md Additionally, we have the added complexity of issues crossing repo boundaries. We could always ensure we have a ticket in the repo we are committing to, but then replicating tickets isn't necessary ideal either. I guess my point is, if we go with issues or commit messages, I'm not sure what we do better than we already do? For the issue titles, we could create different issues titles that talk about what is actually done, versus the requirements, but then we lose the ability to autogenerate requirements from our issues (which almost an equally laborious manual task). |
Beta Was this translation helpful? Give feedback.
-
That being said, maybe we do just need to change the way we are managing our requirements... |
Beta Was this translation helpful? Give feedback.
-
@jordanpadams is the usage of the release description in the github form implied by one of your proposed options ? There is a also an 'auto-generate description' button which I think is based on pull requests but I did not manage to make that work. For the comments before, to be honest I am not paying a lot of attention to the generated changelog. Maybe we should validate them more carefully when we create a release if they are not too far from what the users expect. The issue then is going to be that if we want to adjust the tickets titles or presence (harvest does not have any ticket for release 3.5.2) we would have to regenerate the changelog multiple time manually for the same release which is not easy with the current CICD. |
Beta Was this translation helpful? Give feedback.
-
@tloubrieu-jpl yes. I kind of meant that by (c). The auto-generate description won't really work because our last push to the repo is almost always the changelog updates from the CICD |
Beta Was this translation helpful? Give feedback.
-
I don't know if this is something that can or even should be automated. Maybe how they're stored or presented, sure. But their content? Nah. Good release notes should assuage fears about changes to things they like, detail what's changed since last time, provide motivation to update, give only those technical detail so folks can make a mental picture of what the effort's going to be. They should be grouped so people can gravitate to the parts that are relevant to them, such as "new features", "bug fixes", "security updatess", etc. On top of it all, they: should be a joy to read: sufficiently engaging to keep the interest, brief enough to get people through them all, and a hint of playfulness to make the entire ordeal seem not so bad. "Playful has no place in software." Really? If that were the case, we wouldn't have the Google Doodle! This doesn't mean every bullet item in the release notes has to be a joke. But having a little humor in at least one of them can help make the medicine go down. Because of all this, I don't see a good way to automate it. I'd have a good technical writer look at the changelog for a release and turn that into a decent set of release notes. Example Release NotesWhat follows are excerpts of actual release notes I've read recently that I think stand out as good examples. Example Release Notes for 1Password on MacOSToday's release brings a number of improvements to file attachments for 1Password accounts. We've also made a number of improvements to browser integration, making sure 1Password is filling fields as deftly as possible. Improvements
Fixed
Example Release Notes for Slack on macOS
Example Release Notes for ProductPlanSee 'em here: https://www.productplan.com/release-notes/ |
Beta Was this translation helpful? Give feedback.
-
@jordanpadams wrote:
Just to throw this out there, tickets can be cross referenced from any repo. The syntax is this: |
Beta Was this translation helpful? Give feedback.
-
proposing release notes in release descriptions. started a release guide here: https://github.com/NASA-PDS/nasa-pds.github.io/wiki/Release-Notes-Guide |
Beta Was this translation helpful? Give feedback.
-
💡 Description
Looking to standardize some common way for we, the PDS, should capture release notes for releases of software components.
Right now, we use the CHANGELOG as our primary view of what has changed, but that tends to be too technical/granular for the everyday user. We need some simple, manually curated release notes to describe in more user-centered terms what is new, what is fixed, and any backwards incompatibilities. Let's use this issue to throw out some ideas, and we can talk at the 2/3/22 breakout. What I am looking for:
(1) common mechanism for capturing these notes (some file in the repo, a page in the online docs, etc.)
(2) what do the release notes actually look like? - a consistent format for how we present this to this to the user
Let's start the discussion on (1), and then we can switchover to (2) once we have some ideas. If folks know of good best practices out there for this, that would be ideal so we are not re-inventing the wheel.
Some ideas to get us started:
a. Add a RELEASE_NOTES.md at the top of every repo that we link to from our documentation.
b. Use Github discussion threads - I did this for a validate release to just see how it might work
c. Include the notes in the actual tagged release on Github - You can actually put a custom description on these release pages
(a) seems like the easiest solution with the least amount of effort. we would just need to add this to our procedures for our "release engineer". (b) or (c) would be nice, but would require more manual clicking through the repos and/or update to roundup
Beta Was this translation helpful? Give feedback.
All reactions