Conversation
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
|
thanks! i plan to review this, and maybe document the monthly update side in more detail, once i finish the monthly update. |
Co-authored-by: Josh Matthews <josh@joshmatthews.net> Signed-off-by: Jonathan Schwender <55576758+jschwe@users.noreply.github.com>
| At the end of the month, prepare a branch based on latest `main`. | ||
| Run `./mach release X.Y.Z` to bump the version numbers and commit the changes. | ||
| Open a pull request on servo, to merge the branch into `main`. | ||
| Ideally, the pull request is merged timely on the last or the first day of the month, so that the version number bump correlates closely with the blog-post range. |
There was a problem hiding this comment.
regarding the commit we base the release branch on, any deviation from the head of the last nightly release of the month (UTC) would create a gap between the monthly release and the blog post, due to the procedure for blog posts. but i think the big thing we want to avoid is for changes to be present in the blog post but missing from the monthly release, so i think it’s ok if the monthly release is “later” than the contents of the blog post.
it may be worth clarifying this, although i guess deviations in either direction can be fixed by rebasing the version bump commit when creating the release branch (as you explain in the next section)?
There was a problem hiding this comment.
I pushed a suggestion to help clarify this. Out of curiosity, why doesn't the blog post go up to the nightly of the first day of the month (since that should be close to 0 am, i.e. not yet contain any significant changes from the new month).
There was a problem hiding this comment.
thanks! ultimately the reason was just that it was simpler to implement – notice how the sed '/^>>> 2025-01-/,/^>>> 2025-02-/!d' cuts off any nightlies with .updated_at in the next month. but i did a bit of digging: since the nightly builds start at 22:15 UTC each day, the first nightly of the next month includes at least 22 hours of changes in the next month.
There was a problem hiding this comment.
Ah right, we recently changed the time to be slightly before midnight. In that case it makes perfect sense to keep as is.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
|
sorry, i intended to finish reviewing this today. looks good :) |
3 participants
No description provided.