#axum-internals

303 messages · Page 1 of 1 (latest)

marble scroll

Thanks @mental sequoia for setting up the channel!

@leaden dock @lucid carbon @mighty glacier @raven karma 👋

raven karma

👋 hello everyone

marble scroll

Hey! I just finished adding an LLM contributions policy to my number 1 open source project by time spent contributing. I would love for axum to adopt the same or a similar policy, though based on some of @mighty glacier's toots on Mastodon I would assume that there is no universal support for this in this group. Still (or maybe especially due to that), I wanted to share it and hear what all of you think about it:
https://github.com/ruma/ruma/blob/8ea125307fc6876ad4416617b4a416e4b10369b2/CONTRIBUTING.md#llm-contributions

Also, I realize I haven't pinged @tidal skiff in this room. Just so you know this room is a thing now 🙂

unborn forge

Generally, tokio as an org aims to follow the same policies as rust-lang. Since we are a bigger group, it helps. If it is something you want to drive, you could propose it at the rust-lang level

An LLM contribution policy really should be something that is consistent at the org level as well vs. a per-project

If an LLM contribution ban is universally supported and considered highly important within the axum maintainers, we can have that conversation

A complete ban due to ethical objections is also a lot stronger than a soft ban on the basis of contribution quality

marble scroll

I definitely don't have the appetite to push for this at the rust-lang level. Maybe I'll create a simple poll about rough opinions about the topic on IRLO 🤔 (but even that seems like it will lead to a lot of discussion which might be taxing to keep up with)

Anyways, I do still think having this conversation in this smaller group is valuable. Even if we can't have a policy just for axum (which I totally understand).

unborn forge

I expect that taking an official llm contribution ban at the tokio-rs level will be equally challenging, mostly because I have taken the policy of defering to r-l on these sorts of policies

uncut kelp

(sorry for chiming in on this) There actually is a proposal for this at the rust-lang compiler-team level, see here

marble scroll

@uncut kelp no need to feel sorry, thanks for the info 🙂

unborn forge

Generally ^^ is much different and probably a good idea

regardless of the source (LLM / Human) I am pro quick rejection of PRs that create undue burden

uncut kelp

It's definitely not an LLM contribution policy, but it's the minimum that people could agree on for now AFAIR

mental sequoia

I don't really agree with a blanket ban. People are responsible for what they submit of course, but I'm happy for people to have AI help them code.

unborn forge

there is also a big lack of clarity w.r.t what is an LLM contribution. If a contributor uses an LLM to get situated in a project (ask questions about architecture or how a change should be made) then does the rest of the work themselves, is that an LLM contribution?

many questions, which make these sort of policies hard, which is why I just punt to rust-lang as an org to do the heavy lifting there 🙂

there are also open LLM models that generally don't have the ethical issues that the big closed ones do (except quality, as they tend to be worse)

marble scroll
unborn forge there is also a big lack of clarity w.r.t what is an LLM contribution. If a cont...

I have not seen this be a point of contention, honestly. The policy I just agreed on with the other maintainer of Ruma (i.e. the doc I linked earlier) says that contributions must not contain content generated by LLMs. I do think using an LLM at all should be discouraged (my no. 1 reason for bringing this up is ethical), but I don't think it is reasonable to go as far as banning all uses of LLMs, especially because some things like getting to know a project might involve accidental use of an LLM (e.g. Google AI overview), or use of LLMs for accessibility (e.g. translation of a PR description, if a contributor does not speak English natively well enough).

marble scroll
unborn forge

Personally, I am fine w/ the undue burden policy Adrian linked above. It will be especially easy to follow rust-lang since it looks like they are moving in that direction anyway.

I expect agreeing on a general LLM ban at the org level to be hard, both within rust-lang and tokio-rs

if it is a universal deal breaker for axum maintainers, we can have that conversation and figure out a way forward, but I am hesitant to have per-project contribution policies

indigo lichen

Re: tokio-wide policy, tokio-metrics maintainers would generally not want a blanket ban, at least without substantially more discussion.

From a functional angle, our project is actually a pretty good candidate for llm PRs since it involves a lot of fuzzy mapping of concepts from the tokio repo over to our higher level abstractions. Good "super find and replace" fodder.

That said the ethical concerns are real ones hence being open to a deeper discussion about it.

marble scroll

Well, I guess I can make a short list of ethical concerns I personally hold:

indigo lichen

I would suggest moving this into a more persistent place if trying to go deeper into a discussion to suggest tokio policy, honestly rust lang might make more sense than tokio if going to that effort. @unborn forge can probably suggest a good venue though.

In general I acknowledge a lot of these points but tend to be skeptical of the practicalities of enforcement (detection related). I think it might be more effective to suggest contributing under X less morally dubious model with clear instructions on how to do so. I don't think people are likely to stop using llms entirely, they just will lie about it or contribute elsewhere. So better to bridge the gap.

Also somewhat skeptical of the political efficacy of individual repo action of relatively small orgs like tokio. But influencing orgs like rust lang to take stances might have better efficacy, if they will go for it.

marble scroll

I am rather confused about this notion that people who take their free time to contribute to open source would intentionally violate a project's policy and lie about it because of an inconvenience. I think it is far more likely that people who want to use LLMs would instead oppose / seek to change the policy.

tacit geode

people will absolutely lie to it, OSS contributions are de facto an expectation of a lot of software recruitment nowadays and there's a perceived benefit in having a history of contributing to popular projects even if they're just drive by contributions. Some people will absolutely try and game github contribution graphs with low value LLM PRs and lie about it because of that belief of a financial benefit to their career

also there's already been a number of low effort LLM written rust RFCs where the user has tried to deny they used LLMs and the RFC just described something already a feature in Rust but with dumber syntax compliantsmiley

marble scroll

I can see that but then I do not think any policy is going to substantially change how such PRs are treated. As a maintainer, I do not need a policy to point to to call out and reject obviously low-effort PRs, whether an LLM was involved or not. A policy could potentially dissuade some such stats gaming attempts though.

tacit geode

yeah but aside from low effort ones or tells like weird excessive comments you can't really tell if someones used an LLM or not, and a lot of people won't read or will just ignore the contributing. Maybe not with malice but rather their own threshold of what "LLM written is". Such a policy is going to be unenforceable and you'll only realise so because of the easy-to-catch instances 👀

I don't disagree with such a policy, I don't like or use them for coding myself generally. But if I added such a thing to one of my projects, I'd do so more of a signal on the values of the project rather than something I'd expect people to follow fwiw

marble scroll
marble scroll

@leaden dock @lucid carbon @raven karma any thoughts on the above? I've already mostly given up on pushing for a policy, but would like to hear your opinions anyways.

raven karma

I agree with the overall consensus here it seems. I don’t care so much about the tooling used. As long as they take responsibility for it.

Had to stop some in the past as they were overly verbose in both the comments, descriptions and approach.

Othertimes I notice but it’s acceptable as you can’t nitpick to much in a big enough (oss) project.

And there are probably plenty of times where I don’t notice at all, especially if used in tandem with other tools by a skilled dev.

marble scroll

I feel like my point is being missed once again ._.

raven karma

I suppose it’s more about the politics / ethics / morals for you, no?

marble scroll

I did not post this because I'm annoyed about low-quality PRs as much as I posted it because in my close-people bubble, LLM use is generally seen as unethical, and I wanted to hear what you as co-maintainers of one of the projects I'm involved in think of that.

raven karma

I feel you. I wouldn’t mind a world where it didn’t exist at all. But that goes for many things in the world. In the end a lot of the unethical things are not all that unique to LLM but stem from much bigger issues.

Practically/policy wise I agree however with the above.

And personally I would suggest to projects and maintainers that don’t want anything to do with LLMs to move away from GitHub. Seems to me like a more meaningful change and signal if you ask me.

I’m however indifferent to it all, or try at least. For better or worse.

marble scroll

In the end a lot of the unethical things are not all that unique to LLM but stem from much bigger issues.
I guess how LLMs are different to me is that (a) the numbers around energy usage (esp. projected) are just completely crazy and not comparable to anything else that is so close to not existing, both in how new it is, and in how little of it is going to be left when the hype bubble bursts... and (b) relatedly, how easy it is to "opt out" (refuse to be a part of the problem).

And personally I would suggest to projects and maintainers that don’t want anything to do with LLMs to move away from GitHub. Seems to me like a more meaningful change and signal if you ask me.
I disagree about it being a stronger signal, but more importantly, I think it is way harder to implement / has much larger downsides.

raven karma

Fair

Discussions like this strangly remind me of oppositions like in https://youtu.be/XMm0HsmOTFI?si=qYvJt33A8MK3Ri7X.

because as much as I admire and appreciate someone like a stallman. I feel more in line with Linus his approach in such things. And try to keep out of politics and all that. Especially not gonna mix it with my open source work.

marble scroll

See, this is where things get interesting

I don't think of my position as being nearly as hard-line as Stallman's / the FSF (USA)'s positions on software freedom

(I also don't think highly of Stallman or the FSF)

Also, surely as part of the Rust community you've heard "there is no such thing as being unpolitical" or some variation thereof?

tacit geode

YesYesYes anything which shapes power structures is inherently political

marble scroll

Eww that gif 😅

tacit geode

I see it pretty much daily, it's just vibes for me now

there's a weird thing on LLMs where the more they're used the more money companies lose on them and the less economically sensible they become. But also the more destructive they are to the environment. So it's kinda a lose lose right now

related side note, I can't see tokio ever adopting an anti LLM policy because amazon have a vested economic interest in LLMs succeeding and if tokio counters their interests there's no reason to economically support tokio shrug

marble scroll

"ever" - you mean before the bubble bursts 😉

eh, probably doesn't matter past that anyways

tacit geode
marble scroll

Yeah, forget I said anything about that, that thought leads nowhere

tacit geode

also if a government doesn't want it to the bubble won't burst (this is how agriculture is kept semi-profitable in the majority of the western world)

marble scroll

There's a limit to how much stupid a government can do before things really go south

tacit geode

bit doomerism but there was a lot of unprecedented bailouts with the mortage crisis and they didn't put as much money in as AI investors

as long as GDP goes up and people don't protest too much it doesn't matter how much living standards drop (neolib brained economics)

idk since 2007 it's been a general consensus in the UK that life gets worse every year in terms of cost of living and general quality of life so I'm probably just too cynical on it

marble scroll

You live in UK?

tacit geode

Yeah

marble scroll

Not the first time I hear bad things from over there

tacit geode

I have friends that bought a house on £18k pa household income and raise 2 kids

so there's benefits compared to the US in terms of cost of living

but public services are in a state of free fall and everything's bleak

marble scroll
tacit geode

Ah nice, I follow some solarpunk stuff on youtube ok_hand

marble scroll

(you have to mute a bunch of "hey look at my photovoltaics stats for this month" and LLM image spam profiles posting there though)

tacit geode

there's a climbing gym in london that has their own community garden with some vegetable patches etc and it's nice following them

marble scroll

Very cool 🙂

tacit geode

I spent 4 months of this year farming and that was pretty rewarding compared to the normal tech grind (rice farming in rural japan)

marble scroll

I wonder if we should take this hopelessly-offtopic chat elsewhere though 😂

tacit geode
leaden dock

I don't feel as strongly about it but I would agree to some form of discouraging it on principle. Though I think any form of a hard ban is impractical and unenforceable so I wouldn't go that far (but then again wouldn't oppose it if it came to that).

I'm pretty much indifferent to it at this point and I thought of it as not that useful as opposed to actively harmful, but that's maybe because I didn't read enough of how bad it really is resource consumption-wise.

marble scroll

Thanks for sharing your opinion 👍

Same for you Glen, of course

lucid carbon

same opinion as @leaden dock for me.

lucid carbon

Hi, does someone have news about David? Why he suddenly disappeared from the project? Burnout?

marble scroll

I think @unborn forge was the last person to be in touch w/ him (many months ago)

unborn forge

He didn't share details, but reading through the lines, that would be my guess

marble scroll

Hey. Any opinions on when to do the next breaking releases? Somebody opened a discussion about it.

I don't see a strong need to do it soon (I've been meaning to backport all non-breaking changes soon)

@leaden dock you have been most active so I think your opinion should be weighed the strongest

leaden dock

I don't think there's anything we need to release soon either.

quaint panther

Hi @unborn forge , is there a plan to upgrade axum-extra crate to depending on prost 0.14? What would the eta look like for that?

unborn forge

@marble scroll ^

marble scroll

@quaint panther no plans for me, but I'm happy to review a PR, and backport to the axum 0.8 release line

quaint panther
marble scroll

Cool. I'll merge it soon.

quaint panther

@marble scroll Thanks, appreciate it. My team needs this pretty urgently so please let me know when you can get to it

rough wraith

Hi!
I was thinking about contributing to some open source projects. What's the best way I can contribute to axum?

And do you think it's possible to contribute to something you don't use often?

quaint panther

@marble scroll Just added the changelog entry as you requested.

marble scroll

@quaint panther I'm guessing you also need a release? Or is depending on the git repo fine, knowing the git rev will be stable now?

@rough wraith unfortunately I don't really have much time to on-board new contributors, nor do I know of good first tasks in axum. I would recommend you check with other projects.

(there are other maintainers who may be interested in contributor onboarding / mentoring)

rough wraith

Thank you
Yes if there is anyone willing to onboard me, please let me know. I'm not completely new to axum I have explored the codebase a bit before and I used it myself for some toy projects

quaint panther
marble scroll

Can you make an issue for it? Thx.

Also since you were talking about your 'team', sounds like you're using axum in a professional setting. If you could set up sponsorship for on GitHub (even low amounts), that would definitely increase my motivation to spend time maintaining axum 😉

The same may be true for mladedav who also has GitHub sponsors and is doing a lot of axum maintenance (plus answering many questions in the Q&A section!) these days.

quaint panther

@marble scroll I created an issue for it here. https://github.com/tokio-rs/axum/issues/3531

Let me know if there is any way I can help with getting this released. This is indeed for professional setting but I don't really have any control over budget or contributions to open source. Will definitely ask around for you but no promises 🙂

quaint panther

Hey @marble scroll , please let me know if there's anything else I can help with at all, would love to see the new vesrion of axum-extra released soon 🙂

lucid carbon

@quaint panther are you aware that you con configure your cargo.toml to use a git hash directly? No need to wait for a release.

quaint panther
marble scroll

Hey, sorry but life is not giving me much energy for open source work right now. Maybe next week.

@leaden dock are you available for / interested in doing release work again?

leaden dock

Sure, just axum extra, right?

marble scroll

Yeah, from the v0.8.x branch (or a new extra-v0.12.0 branch starting at the current v0.8.x rev). Has to be 0.12.0 bc. 0.11.0 exists already (yanked)

No need to make PRs for the backports, just backport everything that doesn't depend on changes in axum(-core) that aren't in v0.8.x

Then make the release commit + merge-to-main PR and I can take care of the rest

novel needle

<@&1207366540299735151>

sleek turret
quaint panther

Hi @leaden dock / @marble scroll , good evening folks, just wanted to check in and see if there's anything else I can help with in getting the new axum-extra version published, I know life has been tough for folks so I super appreciate any time y'all are able to put into open source stuff, not trying to push into that, but just seeing if there's any way I can alleviate burden and help move things along

leaden dock

No, there's a PR up, we just need to do some checks and the release to crates.io. You could try using this commit to see if there's anything you need missing. cbb8edcda8f8f114cc9beae062cbee77e8c1a826

marble scroll

@leaden dock does a release branch exist? As in, a branch that has its latest commit at where the release should happen. Or did you want me to release from the commit right before the last on your branch?

leaden dock

There's no release branch, the idea was to release the penultimate commit. I think we'll want to point the v0.8.x branch to the commit we release.

I still gotta doublecheck/fix the changelogs though.

marble scroll

I'm a bit confused then, did you not already backport stuff to v0.8.x? As in, is that not what your branch is based on?

leaden dock

I started from the v0.8.x tip, backporting onto that but I didn't want to update the v0.8.x branch so that it still points to the latest releases and so that it doesn't have to change if the backports change before release.

Now I have there two branches, dm/axum-extra-0-12-0-release is the one that should be released and then we can move the tip of v0.8.x onto it. dm/axum-extra-0-12-0 is that merged with main which we then merge back into main so that we have the changelog and version bump.

marble scroll

Okay nice, I will get to the releasing

marble scroll

@quaint panther it's out

marble scroll

Hey all. So, I've been thinking about my involvement in axum as the only major project I spend my free time on that doesn't have an (anti-)LLM policy. The long and short of it is that I can no longer bear being a maintainer on a project that turns a blind eye to all the harm being done being done by "AI" companies.

I've been chatting with @iron moat who has fortunately been available again lately. Unfortunately, he made it clear that he does not want to detach axum from tokio, which was my only realistic idea for how to keep things going roughly as-is.

@leaden dock @lucid carbon @mighty glacier @tidal skiff @raven karma if any of you are interested in starting a fork, let me know. My only ask is an LLM policy that at least acknowledges the issues around using this tech and discourages its use. (I would of course prefer something stronger than just discouraging its use, but this is my baseline for being involved)

lucid carbon

Hi @marble scroll .
I'm not interested in starting a fork.
I do agree with have an LLM policy.
I don't know how to move forward, like who can write this policy, if it would live under "tokio" or only under "axum".
Once we agree on the first steps and the responsiblities, then we can start discussing the content of this policy. I won't start this discussion now as I'm afraid it can be a distraction before we all agree on the first steps.

marble scroll

Is that actually a possibility? When I brought it up originally, the response was very discouraging (#axum-internals message)

lucid carbon

I personally don't know. I only help maintain axum. I didn't have much more knowledge on this topic.

unborn forge

I’m not really around until after the weekend but I will catch up then and we can figure out the best path forward. Like I said when this first came up, there are options. It would be helpful to clearly define what your principles are because “no LLM” is too vague. It conflates your real issues with them and the technology and there isn’t much I can do to accommodate your goals. That said, toasty for example is being built almost entirely with LLMs so as an org I do t want to ban them and per project is confusing

marble scroll

My issues are exactly those described in the article I linked above¹. I'm having a really bad day, not just because of this topic, so forgive me if I'm being very terse. But a project that builds (some) stuff "almost entirely with LLMs" is one I want absolutely nothing to do with. I'm leaving the tokio org on GitHub and this Discord server². I'll keep the contributor status on the axum repo for a while unless you decide to kick me out, I suppose. Contact me on Signal if you care (jplatte.443).

¹ correction: apart from having a somewhat different take on the copyright situation
² edit: well I'm back on Discord temporarily; not sure for how long

unborn forge

Sorry to hear that. It is your choice and I respect it. I personally disagree with the position in the article but that is OK. Either way, I appreciate the work you put into maintaining Axum. Feel free to DM me at anytime as well.

@iron moat @leaden dock @lucid carbon @mighty glacier @tidal skiff @raven karma we can continue the conversation here or feel free to DM as well.

lucid carbon
unborn forge

Looks like martin got to it, but feel free to ping me as well

pastel relic

Hi, senior C++/Rust dev interested in contributing.

forest nova

Brazilian

lucid carbon
unborn forge
unborn forge
lucid carbon
unborn forge

I believe I can setup release-plz?

then it can be done via PR

@lucid carbon can you and the maintainers confirm you are good w/ release-plz?

lucid carbon
lucid carbon
mental sequoia
lucid carbon
lucid carbon
mental sequoia
lucid carbon
lucid carbon

I thought that we were using the main branch for releasing but it seems that we're using the https://github.com/tokio-rs/axum/tree/v0.8.x branch, isn't? So I'd need to cherry-pick the changes that we want for the next 0.8.9 version right?

mental sequoia
lucid carbon
lucid carbon
mental sequoia
cosmic plinth

Bro

Man

lucid carbon
marble scroll

MSRV changes have previously not been taken as breaking changes

lucid carbon

I'm opening https://github.com/tokio-rs/axum/pull/3699 for the next releases. Please review carefully and give me feedback.
Once this is approved, we need to do the following steps I guess:

  • merge into v0.8.x branch with a merge commit
  • tag the merge commit with the different versions
  • proceed with releases
  • merge the v0.8.x branch into main with a merge commit
    ?
marble scroll

I've previously just been cherry-picking stuff onto the v0.8.x branch, then opened a PR merging it back to main and linked to the actual diff (last tag on v0.8.x vs. head of v0.8.x) there for reviewing.

But two PRs works too

For the v0.8.x into main thing, you'll need a separate branch which contains the finished merge commit, as GH doesn't let you do custom merge commits (resolving conflicts) in the web UI in a non-stupid way. Then once that is approved, fast-forward (git merge --ff-only) main onto that commit. (github will take this as merging the PR)

lucid carbon

thanks for the help!

lucid carbon
mental sequoia
lucid carbon

Should I add the git tags to the merge commit?

mental sequoia
marble scroll

This is backwards to how I've always done it (I started from main and merged the release branch into that rather than the other way around), but should be fine.

However, CI should definitely succeed on that branch and the Cargo.lock update seems a bit weird – I'd make a separate PR for that and then redo the feature merge.

You're probably going to want to enable git rerere if redoing merges (though now it'll be too late to have it record your manual merges, and anyways it only works on files that fail auto-merge)
https://git-scm.com/book/en/v2/Git-Tools-Rerere

lucid carbon

Thanks both of you. I'll tag the release, and then take care of the merge in a new PR.

midnight bolt

Hi folks, I'm looking for a pair of eyes on this PR: https://github.com/tokio-rs/axum/pull/3704
It's a (hopefully not too invasive) addition that allows setting a custom executor on serve. It would help us a lot on dial9-tokio-telemetry with observing axum's spawned tasks without rewriting serve entirely

Btw I opened against main before seeing the earlier conversations here about v0.8.9, if this is something you'd include in that release I can open a PR against that as well (or whatever is preferred)

lucid carbon

As we have several releases, can I add multiple git tags to the same commit, or is it better to have them on separated commits?

mental sequoia
lucid carbon
mental sequoia

Are the commits already merged into main?

I saw the PR is still a draft.

lucid carbon

No, there are only in the v0.8.x branch. I'll now create a new PR for the merge.

I did not know if we release from the v0.8.x or from the main branch.

lucid carbon
mental sequoia
lucid carbon
mental sequoia
lucid carbon
marble scroll

The release definitely needs to happen from the v0.8.x branch ^^

Why are there revert commits for the release commits on the branch?

lucid carbon
marble scroll

Then something is broken, if main had a newer -core version than v0.8.x

lucid carbon

Then let's not release and find out the issues before continuing.

marble scroll

Could it be we just haven't had any breaking changes to axum-core on main since v0.5.0?

In that case, you can just do another v0.5.x release from main (v0.5.7)

lucid carbon

Is it a general "rule" that axum-core is released from main whereas the other crates are released from the v0.8.x branch?

marble scroll

Or maybe we didn't with v0.5.6 but do now? In which case I'd start a core-v0.5.x branch off of the last commit before breakage.

The general rule is to use separate "release train" branches once breaking changes have been merged to main.

After any major release, I've been holding off merging breaking changes at all for a while, so releases could continue to happen from main. But of course once you've got multiple people wanting to make breaking changes to the same area of the code, that no longer works, so then breaking stuff is merged to main, we added this small warning to the readme: https://github.com/tokio-rs/axum#-breaking-changes-
… and releases were moved to a branch.

Though maybe it isn't the best workflow. I'm pretty sure that warning made it into one or two crates.io uploads because I forgot to remove it as part of the next breaking-change release ^^

mental sequoia

I mean, I think the two branch workflow is the right one, with regular merges from the old versoin to the new version, but not the reverse.

lucid carbon

Having a release branch for axum v0.8.x and another one for axum-core v0.5.x is quite complex. If it's possible, we could use the v0.8.x branch for all releases, including axum-core.
The process would be:
in the v0.8.x branch:

  • cherry-pick all non-breaking changes from main that we want to release. (this could be a continuous process)
  • update the release notes and push a git tag. The cargo publish could be done from those tags.
    in the main branch: merge the changes from the v0.8.x branch
    WDYT?
marble scroll

I think it will be a bit annoying to find all the relevant axum-core commit since v0.5.0. If you do it wrong, you end up undoing some changes from prior core versions.

Maybe put out axum 0.9.0 soon and do the release branch for all crates approach next time

Also +1 on semver-checks

(+ separate semver-comment.yml)

mental sequoia

I think I agree that having three branches is going to be tricky, because you will not be able to merge from axum-core branch into axum 0.8 branch, so axum 0.8 won't be able to use new axum-core features via the workspace.

marble scroll

That's debatable put personally I wouldn't put it in a semver-compatible release

It changes user-visible behavior, and while the previous behavior could be called buggy I wouldn't be surprised at all if people were relying on it / expecting it

mental sequoia

Is an axum-core 0.5.7 needed? If not, we can just skip that crate and make the next release an 0.6.0

lucid carbon
unborn forge

I would suggest moving to release-plz. I've been using it some, and it does seem to work better if you follow its conventions re: changelogs, but if you do, releases are super easy

tranquil breach
lucid carbon

In the meantime, should we proceed with the releases I've prepared?

mental sequoia

Is there anything you'd like to fix before I do a release?

lucid carbon
marble scroll

I'm not aware of anything that needs fixing but also didn't look closely at the stuff you backported

(nor do I intend to, it might appear I'm no longer upset about the whole tokio / LLM policy situation given I've been helping out again above, but I definitely still am and don't want to become a maintainer again)

(also conventional commits make for very bad release notes, just saying..)

unborn forge

The changelogs can be edited in the PR before hitting release

lucid carbon
mental sequoia

If you think they are ready, please tell me which of the tags you want published.

lucid carbon
mental sequoia

axum-v0.8.9, axum-extra-v0.12.6, axum-macros-v0.5.1 ?

lucid carbon

To minimize the risks, we can also start with one release only, wait a few days, and proceed with others later.

mental sequoia

To me the bigger question is whether there are ordering concerns.

I see the axum-macros commit is on top. Does this mean that the axum release does not depend on axum-macros being released first?

Most of the time, macros crates are released first, after all.

lucid carbon

Let me check more

mental sequoia

Unfortunately, the axum crate doesn't compile on the axum-v0.8.9 tag.

lucid carbon
mental sequoia 
error[E0432]: unresolved import `axum_core::response::IntoResponseFailed`
 --> src/form.rs:3:41
  |
3 | use axum_core::response::{IntoResponse, IntoResponseFailed, Response};
  |                                         ^^^^^^^^^^^^^^^^^^
  |                                         |
  |                                         no `IntoResponseFailed` in `response`
  |                                         help: a similar name exists in the module: `IntoResponseParts`

error[E0432]: unresolved import `axum_core::response::IntoResponseFailed`
 --> src/json.rs:4:41
  |
4 | use axum_core::response::{IntoResponse, IntoResponseFailed, Response};
  |                                         ^^^^^^^^^^^^^^^^^^
  |                                         |
  |                                         no `IntoResponseFailed` in `response`
  |                                         help: a similar name exists in the module: `IntoResponseParts`

error[E0432]: unresolved import `axum_core::response::IntoResponseFailed`
  --> src/response/mod.rs:22:49
   |
22 |     AppendHeaders, ErrorResponse, IntoResponse, IntoResponseFailed, IntoResponseParts, Response,
   |                                                 ^^^^^^^^^^^^^^^^^^
   |                                                 |
   |                                                 no `IntoResponseFailed` in `response`
   |                                                 help: a similar name exists in the module: `IntoResponseParts`
lucid carbon

Which command are you using? (I'm trying to replicate the issue)

mental sequoia

The cargo publish command uses the versions of crates on crates.io in its build, rather than the one from the workspace.

lucid carbon

ah ok, then we need to publish the dependencies first.

Or I revert this change from the v0.8.x branch for now. Maybe that's the easiest.
Edit: it's already reverted. Just the git tag was before the revert

I'm still trying to reproduce the issue locally so that I can better prepare releases in the future, but I cannot.
cargo package also works.
and I cannot use cargo publish.

I could reproduce the issue with cargo package inside the axum crate. nice.

All tags are pointing to the same commit

mental sequoia

I think I need to take a better look at the branches to understand the situation a bit better. I'll do it tomorrow.

indigo lichen
lucid carbon

I can have a look when we're over with the releases.

mental sequoia

Ok, I looked it over now, and it looks ok. I did the relase.

lucid carbon
lucid carbon

I had a look at release-plz but it seems to really support publishing from one main branch, and not from mulitple branches as we're doing right now (issue)
It's also one of the question from the talk. This was from 2023, so maybe it's outdated.
Or do you have another experience with it?

Or are you mentioning that with the assumption that we start a 0.9.0 version from main and that we continue from here?

mental sequoia

We can talk to the maintainers of release-plz and ask what they recommend.

lucid carbon
iron moat

Hello there. Long time no see 🙂

I was just at tokio conf where I spoke with @mental sequoia about axum maintenance. I've been MIA for a while for various personal reasons but I'm now back working with rust at gitbutler and would like to help out with axum.

I think it would be rude if I just started closing or merging PRs out of the blue so wanted to ask here first if there is anything specific you'd like help with.

Alice and I talked about the top priority being to finish up the next breaking release and getting release-plz setup (seems that already is in progress). So I will start by figuring out what state things are in and whats missing to cut a new release.

I do have one proposal though: Remove ECOSYSTEM.md. It gets a lot of churn and I don't think its valuable now that axum is mature and has a large ecosystem. What do people think?

tacit geode

As a user I personally didn't even realise it existed, I'd normally just use things I already knew about or search via crates.io. I can imagine it causes a bunch of drive-by PRs of people wanting to add their projects to it (and later dropping those projects) so I'd remove it if it was my project

sleek turret
leaden dock

Yeah, subjectively, there's also been an increase in PRs targeting it lately and there are some projects that target axum versions as old as 0.3 I think.

rustic halo

Remove it 💪

lucid carbon

I'm also for its removal. It's getting sometimes difficult to assess why a project should be part of it or not.

iron moat
lucid carbon
lavish rapids

Hi all I'm new here. I'm evaluating to contribute to axum, so right now just studing the code. But, just a questione, how do you track the v0.9 issues and roadmap? Is there a specific page or label or something else?

iron moat

There is a GitHub milestone with issues currently planned to be part of 0.9

But it’s pretty loose and isn’t some sort of grand plan

past garnet
lucid carbon
mental sequoia

That would be @iron moat or @unborn forge

iron moat

done!

lucid carbon

thanks! Let's try then!

I'd need more reviews.

iron moat

can we test it with a new 0.8 release from that branch? I can cherry pick recently merged commits. There are couple

or does it have to be from main?

lucid carbon

As far as I understand, there will be 2 PRs: one from main and one from v0.8.x.
Here is the one for main: https://github.com/tokio-rs/axum/pull/3745
We can start cherry-picking in the v0.8.x branch, and, normally, a new release PR should be created for this branch.

iron moat

alright, I'll do some cherry picks

iron moat

merged

lucid carbon
iron moat

ah right yes. 2 sec

leaden dock

It seems it will currently just name all the PRs chore: release regardless of the branch. Can we rename the #3745 PR e.g. to chore: release 0.9 or do you think that might confuse release-plz next time it runs? Just so we don't accidentally confuse the two PRs.

lucid carbon

There's only one PR opened: https://github.com/tokio-rs/axum/pull/3748 and I don't understand how it got all those changes. It does not seem to work well for our structure. Maybe it just needs some configuration. Maybe it's not for us.

iron moat

I think its because it created the release branch (release-plz-2026-05-05T12-42-12Z) from main and not v0.8.x

can we configure that?

lucid carbon
iron moat

alright, makes sense.

In that case I suggest we just abandon the current 0.8 release, since there wasn't anything super important, and focus on getting 0.9 out with release-plz. I can revert the PRs I just merged to the 0.8 branch. wdyt?

lucid carbon

I'm ok with that.

iron moat

although its really confused about how to update the changelog 😅

lucid carbon

yep. By default, it considers that the changelog is not updated by each PR, but updated once per release using the commits' messages. We can disable this if it's too noisy. Or we can stop asking for changelog entry for each change and rely on the commits' messages. In that later case, I think that we'll still need to rework the entries for each release to make them easier to understand.