I’ve added sections to each version in the op for “compatibility notes”.
I hear of minor, intentional regressions often, and am very worried that they are not being tagged on the issue tracker. The op here is a simple place to list these regressions when you come across them, letting us sort the details out for the release notes later. Please keep it in mind.
Someone motivated might watch the beta regressions for those that are closed wontfix and add them to the op with links, or better yet, find the PRs that introduced the changes and tag them ‘relnotes’.
I updated 1.17 to match what’s actually being released. All these things didn’t make it:
deprecate rustc-serialize in 1.18?
I don’t think that’s tied to rustc releases, really.
Seems like rustc-serialize is deprecated right now, for 1.17.
Edit: well, actually there’s no patch to the compiler to deprecate the attribute yet. It’s kinda half-deprecated.
…The linked tracking issue was closed by bors when 40870 was merged. That was three weeks ago. I don’t know exactly how the process works, but shouldn’t that mean that this did make it?
It was merged into master. Then it has to wait for the next beta branch (every 6 weeks), and then it’s 6 more weeks to reach stable. So it can be 6-12 weeks total from merge to stable release, unless someone actively backports it to beta sooner.
Okay, so since the 1.18 beta has been branched, I assume this means it’s on track for 1.18?
I believe so, yes.
I am looking for somebody to take over maintenance of the release notes.
Is anybody interested in compiling the 1.18 release notes and updating the milestone predictions? Creating good release notes and telegraphing what is in the pipeline is an important part of the Rust process.
Ideally the notes for the next release are compiled at the beginning of the beta cycle, 6 weeks ahead of the release. That means the time to make the 1.18 notes and update predictions is now.
Below is how I do it. It usually takes several hours of effort, which typically occupies a full day, with other interruptions considered.
Copy the previous version’s section in README.md to a new section and strip out all the items. Reuse the existing section structure, but look out for themes in the release that might warrant other sections. e.g. sometimes there’s a lot of interesting perf commits, or rustdoc commits.
Before I start I find the date ranges the release was on master, for making GitHub queries, and the commit ranges for the entire release, as well as commit ranges for just the releases backports.
I only pick out PRs that impact stable features. Currently, nightly development does not have a place in the release notes. Generally, more exciting items go toward the top of sections. Most items are simply links to the PR that landed them; some that need more explanation have additional, unlinked text; anything supported by an RFC has an additional RFC link. I reuse the PR titles or write my own descriptions as needed for clarity.
The main query I do is against GitHub merges for rust-lang/rust for the correct date range, e.g.:
https://github.com/rust-lang/rust/pulls?q=is%3Apr+is%3Amerged+merged%3A2017-02-02..2017-03-16
Pick out interesting PRs, especially those tagged ‘relnotes’. Because the date ranges are imprecise, I’ll verify commits at the edges of the dates against git, using a command like:
git log `git merge-base origin/stable 1.16.0`..origin/stable | grep $commit
Note that the branches might be different depending on when you compile the notes.
Then I look for the “libs stabilization” PR, which contains a bunch of newly-stable APIs.
Then I check git for the range of backports. Sometimes there are things there worth mentioning that don’t show up in the GitHub query, but most backports are to fix regressions that never hit stable, so aren’t worth mentioning. The query is something like
git log `git merge-base origin/stable origin/beta`..origin/stable
Again the branch names may be different.
Then I do the same with rust-lang/cargo. When RLS is in-tree we’ll do the same with rust-lang/rls.
There may be a GitHub milestone for the release. Check that to see if there’s anything worth talking about.
Finally, compare the results to this milestone prediction thread and make sure they agree, updating the predictions as necessary.
release: 2017-04-27
on master: 2017-02-02 - 2017-03-16
all commits: git log git merge-base origin/stable 1.16.0…origin/stable
just backports: git log git merge-base origin/stable origin/beta…origin/stable
checklist
Maintaining the milestone predictions is a less exact process. It’s best to always be on the lookout for new information about what’s in the pipeline, and update the thread incrementally.
Once a release though I do sit down and look for upcoming features. Generally what I do is:
When I post updates to the predictions I also post a message indicating what was updated.
Looks like a lot of work if it takes you a full day to complete ! That’s only an idea but would it be possible to split the relnotes between 2 people (for instance one takes care of Cargo and the other of Rust itself) so that the workload is split in two as well ?
Personally I’d love to help, but I feel like I would be more a burden than anything given my low knowledge of Rust’s release process. However if I can help just a little bit or even take half of the workload that the new maintainer is going to have, then count me in, I would love to !
Hey, so I gave it a shot. The preliminary relnotes for 1.18. Please let know if there was anything I missed. The only PRs I uncertain as to if they would after the next stable was platform specific stuff like NetBSD cross compiler stuff.
@Cobrand it’s possible. The cargo notes are a small part of the overall release though. It would be good for somebody more in tune with cargo to put them together certainly. For 1.17 I did cargo last and basically just copied PR titles directly into the notes without understanding what they even did.
It is true that having strong familiarity with what is going on in Rust helps a lot. Every time though I solicit reviews of the relnotes PR to get feedback about things I missed or don’t understand, and that helps.
@XAMPPRocky thank you!
I don’t see a “Stabilized APIs” section. Maybe that PR hasn’t been made yet and needs to be backported to beta.
Seems like there are a number of things in the OP’s 1.18 predictions that aren’t on the list (e.g. numeric field names, custom crt linkage). Can you hunt down the status of those and update the predictions to match the relnote?
The NetBSD patch looks to me like it mostly affects the CI for Rust and its own build system. I’d probably not include it.
That said, sometimes it’s worth including PRs about things just to indicate that something is happening. Last notes for instance had lines about ‘preliminary support for X platform’, even though those didn’t affect anything on stable.
I updated the OP to archive the 1.17 predictions. Also added a header for 1.20, August 31. Also bumped cargo 1.0 to 1.19. Don’t think there’s any movement on that. Also added more text to my description of the release notes process, indicating to check the GitHub release milestone, and to bring the milestone predictions into agreement with the release notes.
Yes, there hasn’t been a Stabilised libs PR yet.
How would I update your post on discourse? Or is there another location with the predictions?
Prettier backtraces I can’t seem to find what is, and isn’t in 1.18
Incremental compilation No activity since October, and haven’t seen a stabilisation pr, if that’s needed.
Macro use and reexport
All work related to it has been merged, but the tracking issue hasn’t been updated with the next steps.
Custom CRT Linkage Is blocked by #29717
Numeric field names Is waiting on a documentation and stabilisation to be merged.
Untagged unions No updates after the FCP closed.
I’d like to see non-capturing closures to fn pointers coercion on the roadmap somewhere. It’s looks ready for stabilization.
@XAMPPRocky responses below. A lot of this involves getting info from the respective authors. Don’t hesitate to ping authors on issues to prod them to do things.
The OP of this thread is a wiki. You should be able to just edit it.
The main thing this PR did is eliminate runtime frames from stack traces by default. That aspect of the PR specifically was reverted for 1.17, and restored for 1.18, aiui. I don’t know the PRs that did it though. The original author will know. cc @Yamakaky
There has actually been a great deal of activity, even if it isn’t represented on thread. @michaelwoerister will know the status and have an idea of what timeframe it will land.
@jseyfried will know. I asked for status updates on thread. Seems like it won’t make it for 1.18 if it isn’t turned on by now.
I pinged @josh on thread to see if we can get somebody moving on this for 1.19.
Thanks @XAMPPRocky. Can you see if you can edit the op to punt these items to 1.19 as appropriate?
I pinged the libs team about 1.18 lib stabilizations.
@leodasvacas I added it to 1.19, pinged the lang team on thread, and nominated the issue for discussion to start the fcp process. Thanks for the heads up.