Are there release notes on the nightly builds?

[ZacharyInDallas]

I've seen the release notes for the full release, but haven't seen any release notes for the nightly builds. Are their any notes on the nightly builds that mention the limitations / bugs, bugs that were fixed, new features added with a build?

[robert-hh]

Sure. The commit messages carry information about the changes.

https://github.com/micropython/micropython/commits/master

Edit: you can as well look into the list of merged pull requests.

https://github.com/micropython/micropython/pulls?q=is%3Apr+is%3Amerged

[ZacharyInDallas]

So no text document associated with each night build that explains changes in that build.

[bulletmark]

What's wrong with the commit history that Robert gave you?

Each nightly build is tagged with the master commit hash, e.g. for ESP32 the last two nightlies are:

v1.20.0-261-g813d559bc (2023-06-27) .bin [.elf] [.map]
v1.20.0-259-g0e215a9fb (2023-06-27) .bin [.elf] [.map]

So the "text document" describing all new changes in the latest file, using a local clone repo, is:

$ git --no-pager log 0e215a9fb..813d559bc 
commit 813d559bc098eeaa1c6e0fa1deff92e666c0b458 (HEAD -> master, origin/master, origin/HEAD)
Author: elibdev <[email protected]>
Date:   Tue Jun 20 04:15:42 2023

    webassembly: Make mp_js_process_char asynchronous.
    
    This may also call the garbage collector.
    
    Signed-off-by: Eli Bierman <[email protected]>

commit b2ad7e238b4e6de86aef646d715cf9a8a5144807
Author: elibdev <[email protected]>
Date:   Tue Jun 20 01:56:38 2023

    webassembly: Make mp_js_do_str asynchronous.
    
    This fixes a bug where `gc.collect()` would crash due to
    emscripten_scan_stack being called synchronously within mp_js_do_str.  The
    fix is to make mp_js_do_str asynchronous.
    
    Fixes #10692.
    
    Signed-off-by: Eli Bierman <[email protected]>

[jimmo]

@ZacharyInDallas as @robert-hh and @bulletmark has pointed out, the git history is the official record.

Maintaining release notes throughout the release cycle would obviously be a nice to have, but it's extra work, so instead we (Damien) batches up all that work for the release.

[stinos]

Sidenote: I just created such automated release notes creation tool (based on commit history) for another project, and: still needs manual review because it doesn't work correctly and I came to the conclusion it is simply impossible to fix it. To get an idea of why, here are some examples of what happens:

• commit says 'fixes issue 1234' but that issue was reopened because only one usecase fixed not all. So the principle 'if commit says it fixes an issue, state in release notes it is fixed' might be wrong.
• commit says 'fixes issue 1234' but in the issue tracker the issue is still open so it is left out of the release notes. However, might be that it was just forgotten to close it, or it was reopened to add a new feature request, so it should actually be in the release notes.
• commit mentions no specific issue yet contains changes relevant enough to be in release notes
• ...

tldr; it's extra work indeed and cannot easily be automated

[Josverl]

I quite like the MERGED-PR view, always up to date, 0 maintenance, allows further filtering for port or feature via labels.

Assuming master has a BPR that requires a PR, I think that is very useful

[jimmo]

The problem with the merged PR view is that sometimes we "merge" PRs without actually merging them (i.e. we'll manually rebase the branch into master). So they'll show as "closed", with a comment that says "Merged in ".

The only way to get GitHub to show "merged" is if we click the big green button in the github UI, which is only possible if it doesn't require any modifications or rebasing. Increasingly we're using the "allow maintainers to modify the branch" feature so that this works, but often it's just easier to do the rebase separately.