Breaking changes plan for v2

[svartalf]

There is no ETA for v2 yet, as there are not much important changes were made or planned to be, but at least we can track the things which can be improved or changed:

• [ ] Make override: true input by default
• [ ] Make profile: minimal input by default
• [ ] Replace target input with targets, which will allow passing multiple targets to install
• [x] ~~Support for rust-toolchain file (#21) (not sure yet if breaking change)~~ not a breaking change, yay!

In case you have an idea, feel free to add it in here as an issue comment.

[jhpratt]

Couldn't a targets input be provided, explicitly overriding targef? That would be back-compatible. Alternatively, it could be additive.

[svartalf]

@jhpratt yeah, it is pretty much possible, but this feature does not look that important, so it is easier to postpone it till the breaking release.

Until then, simple run step can be used as a workaround, as this Action guarantees that there always will be a rustup in PATH:

- uses: actions-rs/toolchain@v1
  with: // skipped for clarity
- run: rustup target add my-new-target

[jonas-schievink]

targets would be great to have for embedded libraries that target multiple chip families!

[steveklabnik]

another +1 for multiple targets here

[jhpratt]

Having a toolchains option similar to targets would be useful for some use cases as well. The advantage being the ability to auto-install targets when you know multiple toolchains will be used later on. Having a "toolchains since" option in a similar manner to cargo-hack would be ideal.

[clauswilke]

I'd also like to second the need for multiple targets. This is a situation that arises regularly for people wanting to use Rust as part of R packages on Windows, because R by default builds 32-bit and 64-bit binaries at the same time. (You can't separate it out into two builds, it always cross-compiles.)

How about adding a keyword targets that accepts more than one input, without removing target? In the future, in a breaking changes release, you could then remove target. Or not. I don't see any major problem with having both.

[clauswilke]

Oh, and I forgot to say: Adding an entire step just to add a target, and only on Windows, is annoying and clutters the build script and output. So I'd very much prefer not having to do that, even if it solves the problem in principle.

[EwoutH]

[ ] Make override: true input by default

I just want to say that I hugely support this!