Releases

[UebelAndre]

Why aren't there releases for this repo? I feel like this is something every rules repository should have. Is there anything stopping this repo from having releases?

[damienmg]

We are all working in companies that use a work at head model in which release does not really make sense. As this repositories is supposed to be used at source level there is no compelling reason to have release and release induce toil.

[mfarrugi]

I think that it is useful to tag the minimum (and maximum?) bazel version required, since those are the only breaking changes we have made in the past. This was a source of toil for me in the past, lining things up w/ the very frequent bazel updates. I think the 'live at head' approach has only been the case for contributors, as most people will want to include their changes by using the latest version.

…

On Thu, Sep 24, 2020 at 9:58 AM Damien Martin-Guillerez < ***@***.***> wrote: We are all working in companies that use a work at head model in which release does not really make sense. As this repositories is supposed to be used at source level there is no compelling reason to have release and release induce toil. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#415 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAROG6FWL4WM6O6HOSMVENTSHNGCFANCNFSM4RYKY22Q> .

[UebelAndre]

I think that it is useful to tag the minimum (and maximum?) bazel version required

most people will want to include their changes by using the latest version.

I agree with both of these points.

[UebelAndre]

Would it be possible to get a release? Is there something in CI that tests the oldest supported version?

[mfarrugi]

Sure, but what do you need from a release? It is little more than a tag. It looks like CI can ( https://github.com/bazelbuild/continuous-integration/blob/master/buildkite/README.md#using-a-specific-version-of-bazel), but currently doesn't.

…

On Fri, Sep 25, 2020 at 6:50 PM UebelAndre ***@***.***> wrote: Would it be possible to get a release? Is there something in CI that tests the oldest supported version? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#415 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAROG6GU5BLZJV24MERX5P3SHUNEXANCNFSM4RYKY22Q> .

[UebelAndre]

A release to me is an indication of what kinds of changes were made to a code base. It's little more than a tag but the value in it is the semantic versioning. If a neat new feature was added, I should be able to infer that from the release number.

I think testing should be done on some modern version and it should be up to the contributors/maintainers to keep up with modern Bazel releases and be aware of potential incompatibilities with older versions. But I don't think this testing is all that valuable without releases to represent these kinds of changes.

[UebelAndre]

@mfarrugi @damienmg In the issue linked above, a user had an issue due to change that broke compatibility with older versions of Bazel. I think rules_rust should have releases and they should indicate breakages or changes in the API but if nothing else I believe the changes in #463 call for a new release to communicate.

[UebelAndre]

Also having thought about this a bit. It'd be kinda nice to have a release at 9a8ef69 so it's easier to communicate in cargo-raze what it's target compatibility version is. Since right now cargo-raze is going to potentially generate files that expect newer platform configurations to be added to the repo.

[UebelAndre]

Pinging this again. Can these rules please start doing releases? 🙏

[UebelAndre]

@hlopko @illicitonion Any chance this effort can be revived? 🙏

[UebelAndre]

Pinging this thread again. I think these rules need to adopt a release cadence. It's incredibly taxing for users to have to go digging through commit history to find out what changes they're picking up in any update. A release with a TLDR of the changes would solve for this and is a pattern used by many other rules repositories.

[hlopko]

Thanks for pinging.

Not much changed on my end, I still don't have the neither the bandwidth nor the need for regular releases.

If the main problem is figuring out what changed, I'd be supportive to start keeping a CHANGELOG.md file. There I imagine we would mention notable changes and provide links for relevant PRs.

If there is enough demand from the community (and it seems even @UebelAndre alone checks that box :) I have no objections. Logistics of Github releases require repo write access, and I'm happy to grant that to @UebelAndre (their ~ 57 PRs are quite a record anyway :)

What do others think? @mfarrugi @damienmg @illicitonion @dfreese to ping a few?

[damienmg]

As I said in a mail before I am already supportive in extending the support team (and preparing my retiring from the team maintainers) and @UebelAndre definitely contributions exceed the level that I expect from a maintainer for rules_rust.

I don't have time to do proper maintenance of this repo, nor do I depend on regular release (I am living at HEAD like a warrior :p).

[hlopko]

Hi all, after chatting with many of you I believe we reached a consensus. I'll go ahead and grant @UebelAndre write access. Andre, feel free to use this issue or create a new one in which we can polish details of releases.

A common theme in many discussions was the lack of clear backwards compatibility policy and unclear ownership (for example I clearly can't be trusted anywhere near cargo-related code yet my approval counts :) I'm currently on vacation (coming back next week), and I plan to start these discussions. Feel free to beat me to it ;)

[UebelAndre]

So now that there's functionality for getting a release out there, there are some questions:

1. What are all the things required to actually click the button?
2. What should go in release notes?
3. How do we handle the fact that the last release was years ago?
4. What should the new release number be?

I'd love any and all input. I'm really hoping to have a release in the near future.

[illicitonion]

So now that there's functionality for getting a release out there, there are some questions:

🎉

My own question first:
0. When should we release, and how should we number them?

I think we should release whenever there's a significant non-experimental feature (e.g.: rustfmt aspect, --error-format flag), or bugfix to a non-experimental feature (e.g. fixing trailing slashes in build script env vars, fixing link args when interfacing with cc_library). i.e. we should release whenever someone may want to pull in a new version. It's fine to batch multiple changes together into a release, but we shouldn't ordinarily delay a release by more than a week because we're waiting for something else - get releases into people's hands early.

I'd suggest we aim for semver starting at 0.1.0 and aim to generally be bumping the patch version (because we try to avoid breaking changes to public APIs), and bump minor if we break public APIs.

I think we should aim to avoid breaking API changes, and they should result in minor version bumps.

I'd also suggest that modifying things in //cargo/... to be more true to cargo should not be considered breaking changes, even if they otherwise would be. (e.g. if we find we're setting an env var differently to how cargo would, and we fix that, that's a patch bump, even though it's an observable change in behaviour which may break some compatibility).

I would not consider changes to default or minimum-supported rust of bazel versions to be breaking changes, but we should aim to support the last two LTS releases of Bazel (i.e. 4.x and 5.x), as well as bazel at HEAD, and support at least (completely arbitrarily) 1 year of Rust releases.

1. What are all the things required to actually click the button?

a. Ascertain whether the release is breaking, so we can choose the next version number.
b. Ensure CI is green.
c. Make sure release notes are updated (this may be automated).
d. Press the button.

2. What should go in release notes?

• A list of any breaking changes
• A list of any noteworthy changes (i.e. anything that a user may be interested in, or which has any risk associated)
• Links to PRs or commits for each of the above
• The minimum and maximum known-good bazel and rust versions

3. How do we handle the fact that the last release was years ago?

Ignore them, but start at 0.1.0 (the last release was 0.0.7).

4. What should the new release number be?

0.1.0

[UebelAndre]

I fully agree with everything @illicitonion said in #415 (comment).

My hope is that releases become a light weight thing and are easy to push out.

For now, I think we should create issues to track all the things we want to describe in a release until that process is automated. I think this issue is fine to act as the release request for 0.1.0.

@illicitonion @hlopko @dfreese Anything in particular you'd like in the release notes? Other than the obvious "here's how you use this release (http_archive) and these are the min supported version".

[dfreese]

My initial thoughts were generally:

Only //rust/defs.bzl is considered a part of the versioned public API initially. The only supported platform is Linux x86-64 currently, with best effort for Windows and Mac or other architectures.

We maintain compatibility with at least all versions of Bazel released within the past 6 months, (in addition to @illicitonion's suggestion of the last 2 LTS releases).

We use semantic versioning, with the following details specific for rules_rust

• Major
  • Compatibility break of public api (i.e. //rust/defs.bzl)
  • Change in the min supported version (potentially could break this into major v. minor Bazel versions, but since bumping Bazel touches everything for users, I wanted to be conservative on this)
• Minor
  • Features added to the public API surface
  • Adding compatibility to a new platform
• Patch
  • Any changes inside of //rust/private that fix or improve behavior, unless they significantly alter platform compatibility or behavior.
  • To optionally communicate any significant changes to code outside of the //rust/defs.bzl

I'd lean for just going with v1.0.0 to give us flexibility for being more clear between major/minor/patch.

I'm leaning this way, because I think it's most important that rules_rust really focus on rust functionality.

This is, in part driven by the my thought that cargo_universe feels to me like a fork of cargo_raze, based on PRs google/cargo-raze#407, google/cargo-raze#412, and google/cargo-raze#415. Given the work that is going into bootstrapping cargo universe, it seems like it would benefit from being able to semantically version itself independently of rules rust.

I think we'll end up with a much clearer API for rules_rust if we think about them separately.

[UebelAndre]

This is, in part driven by the my thought that cargo_universe feels to me like a fork of cargo_raze, based on PRs google/cargo-raze#407, google/cargo-raze#412, and google/cargo-raze#415. Given the work that is going into bootstrapping cargo universe, it seems like it would benefit from being able to semantically version itself independently of rules rust.

I agree it feels like a fork. Though, I don't want to independently version things in this repo. If we think something should be independently versioned then I question whether or not it belongs in the project. Though that said, I think a tool for managing external dependencies makes sense to be in the rules. I'd vote for keeping crate_universe in the project (or in consideration for the release versions once it's moved out of 'experimental'). Maybe that's tangential though. In general I like the idea of having more flexibility in releases.

[sayrer]

This issue is getting fairly difficult to navigate as a consumer of both rules_rust and cargo-raze.

I did this PR: google/cargo-raze#425, but it then occurred to me that I might have submitted it to the wrong place.

I don't have any strong opinions about the resolution here, but this issue has been open for almost a year.

[sayrer]

It sounds like there may be some agreement about pulling out a shared crate for metadata + planning, and having both cargo-raze and crate_universe depend on that?

Having done some work on an internal fork of cargo-raze, which adds local crates and tests, I think this idea makes sense. The rendering code that cargo-raze supplies is a perfectly reasonable default, but it is not very easy to customize.

[UebelAndre]

So now that #832 is done, what's in the way of making a release? 😄

[hlopko]

Well, you may know better than me :) I guess we can go ahead and implement the release pipeline?

[illicitonion]

I think we reached rough consensus on this - do we have blockers before releasing our first stable version?

@hlopko @UebelAndre @dfreese?

[UebelAndre]

In general I'm on board with doing releases though I'd like to not include crate_universe binaries in the first one since I don't think the pattern there are in a good state.

[hlopko]

Do you mean 0.X or 1.0?

I'd vote for creating the automation (actual releases, changelog management?) to create releases, create a bunch of 0.X releases, and then when bugs are discovered and fixed we can create 1.0.

What is in scope for the release?

//rust obviously. What about //proto and //bindgen? I presume //test and //examples are out. //tools and //utils are in.

Anything we want to do before 1.0?

There are some pet peeves of mine to which I didn't get to yet, like #843, #637, #622, #601. I think I should start accepting that I may not fix all of them before 1.0 :)

What do others think?

[illicitonion]

Do you mean 0.X or 1.0?

I'd vote for creating the automation (actual releases, changelog management?) to create releases, create a bunch of 0.X releases, and then when bugs are discovered and fixed we can create 1.0.

+1

What is in scope for the release?

//rust obviously. What about //proto and //bindgen? I presume //test and //examples are out. //tools and //utils are in.

Also //cargo but not //crate_universe.

Anything we want to do before 1.0?

There are some pet peeves of mine to which I didn't get to yet, like #843, #637, #622, #601. I think I should start accepting that I may not fix all of them before 1.0 :)

What do others think?

I can be swayed to block on any of those as long as they're going to be actively worked on. I don't think any of them are important enough to set them as indefinite blockers except maybe #601.

[UebelAndre]

I do not think we should do a 1.0. There should be a few 0.X before then. For what it's worth

[UebelAndre]

Finally getting back to this. Does anyone have an objection to releasing rules_rust v0.1.0 by the end of the week?

[hlopko]

I'd say go ahead :)

[illicitonion]

Sounds very exciting! Go for it!

[UebelAndre]

Started a release: https://github.com/bazelbuild/rules_rust/actions/runs/2004339369

[UebelAndre]

oh no! it failed 😞

[UebelAndre]

Going to try to recreate it.

[UebelAndre]

created softprops/action-gh-release#221 to track the failure.

[UebelAndre]

Round 2 was a success! https://github.com/bazelbuild/rules_rust/actions/runs/2004511376

[UebelAndre]

https://github.com/bazelbuild/rules_rust/releases/tag/0.1.0 looks pretty epic

[UebelAndre]

Trying now to make sure the release is properly uploaded to the Google mirror.

[UebelAndre]

bazelbuild/continuous-integration#1347 tracks potentially automating this step

[UebelAndre]

With 0.1.0 out, and the release actions looking good. This ticket is now complete! Thanks everyone who contributed to this!