I think it's safe to say we've all been having lots of fun with setting up WNP for various releases. I'm starting this bug to track any potential ideas we can improve in order to make our jobs easier. At first glance, what we can do is: Short term: To add a separate task, just for releases, in releasetasks[1], that reuses some of the [funsize]Publish to Balrog logic - which at its turn uses logic similar to balrog submitter cli[2] - that can be chained to `push-to-mirrors` step. We only care about: * download the existing balrog entry * copy-paste that * adjust name from "XXX" to "XXX-whatsnew" * add "actions": "showURL", * add "openURL": "https://www.mozilla.org/%LOCALE%/firefox/$MANUALLY_REPLACE_THIS_VARIABLE_CALLED_VERSION/whatsnew/?oldversion=%OLD_VERSION%" % we have the version in releasetasks already * submit this to Balrog Unclear to me yet if balrog submitter logic can be tweaked to send stuff other than Release/nightly stuff but I'm sure we can find a way. Medium term: Improve and show some additional fields in mozilla-release stuff only, specifically in Ship-it like: * releasenotes version * WNP version ... so that we can point to older version for dot releases. e.g. 55.0.2 releasenotes point to 55.0, not to 55.0.2. WNP could do the same. Long term: We can integrate all this logic into balrogworkers when we move releasetasks in tree and have different behaviors as we plan to do (and partially already have) in beetmoverworkers. [1]: https://github.com/mozilla/releasetasks/ [2]: https://dxr.mozilla.org/build-central/source/tools/lib/python/balrog/submitter

Communication to Balrog might be tricky for current releases. We'd need to rely on BBB for the moment which isn't ideal. Maybe we should postpone until we have in-tree releasetasks?

One of the things that's made this tricky in the past is that the What's New Page requirements were not always the same. For example, the URL could be different in more ways than just the version numbers, or the highest version that could get it could be different than "latest release from the previous cycle". If that sort of things has stabilized, it might be easier to move forward with this now. > Unclear to me yet if balrog submitter logic can be tweaked to send stuff other than Release/nightly stuff but I'm sure we can find a way. The API supports it, it's "just" a matter of modifying the submission tools. You don't necessarily need to use those tools either, this might be simpler to do as a new script that doesn't use cli.py at all. I should also note that Nick had an idea about how to make this simpler a long time ago, filed as bug 933152. The tl;dr version is that we would pull properties like "openURL" out of the Release blobs, store them elsewhere, and attach them to Rules alongside a Release. You'd still need a separate Rule for the What's New Page, but you'd be able to avoid duplicating an entire Release. I still think this is the way to go in the medium to long term.

We probably want https://bugzilla.mozilla.org/show_bug.cgi?id=1400016 if we're going to do this - it will make it much easier.

Once bug 1431789 is done, Releases will be submitted in a schema that supports in-Release What's New Page decisions. That bug won't add support for automatically adding the What's New Page information when we do top level blob submission, but it will make it easier for humans to add it later. Fully automating this will likely require Ship It changes to accept a locale list that needs the WNP, and possibly the WNP URL itself.

There's been some work to improve this with helping scripts in bug 1410121. Moreover, we're moving these in-tree in the future and that's tracked in bug 1410121. Closing this for now, feel free to reopen if this bug seems useful.