Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Releases #415

Closed
UebelAndre opened this issue Sep 24, 2020 · 54 comments
Closed

Releases #415

UebelAndre opened this issue Sep 24, 2020 · 54 comments

Comments

@UebelAndre
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

mfarrugi commented Sep 24, 2020 via email

@UebelAndre
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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

@mfarrugi
Copy link
Collaborator

mfarrugi commented Sep 25, 2020 via email

@UebelAndre
Copy link
Collaborator Author

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
Copy link
Collaborator Author

@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
Copy link
Collaborator Author

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.

dfreese pushed a commit to dfreese/rules_rust that referenced this issue Nov 11, 2020
Brought up in the discussion of bazelbuild#463, was that testing against multiple
bazel versions with bazelci didn't seem possible without a fair bit of
work.

Judging based on usage that I have seen, we probably moved too quickly
on bumping the minimum version to 3.0.0, but until we can actually test
against our minimum version, we won't be able to reasonably version
breaking changes as suggested by bazelbuild#415.

This initial PR leaves a lot of on the table in terms of potential
optimizations, and is fixed on Ubuntu 20.04 LTS for the moment.
dfreese pushed a commit to dfreese/rules_rust that referenced this issue Nov 11, 2020
This is currently 3.0.0, but given discussion that I have seen, that was
probably too aggressive.  However, until we test against our minimum
supported version, it isn't going to be reasonable to provide releases
as suggested by bazelbuild#415.
dfreese pushed a commit that referenced this issue Nov 11, 2020
This is currently 3.0.0, but given discussion that I have seen, that was
probably too aggressive.  However, until we test against our minimum
supported version, it isn't going to be reasonable to provide releases
as suggested by #415.
@UebelAndre
Copy link
Collaborator Author

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

@UebelAndre
Copy link
Collaborator Author

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

@UebelAndre
Copy link
Collaborator Author

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
Copy link
Member

hlopko commented Mar 22, 2021

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
Copy link
Collaborator

damienmg commented Mar 23, 2021

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
Copy link
Member

hlopko commented Apr 7, 2021

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
Copy link
Collaborator Author

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
Copy link
Collaborator

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.

  1. 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
  1. 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).

  1. What should the new release number be?

0.1.0

@UebelAndre
Copy link
Collaborator Author

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
Copy link
Collaborator

dfreese commented May 11, 2021

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
Copy link
Collaborator Author

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
Copy link
Contributor

sayrer commented Jul 5, 2021

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
Copy link
Contributor

sayrer commented Aug 2, 2021

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
Copy link
Collaborator Author

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

@hlopko
Copy link
Member

hlopko commented Aug 13, 2021

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

@illicitonion
Copy link
Collaborator

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

@hlopko @UebelAndre @dfreese?

@UebelAndre
Copy link
Collaborator Author

UebelAndre commented Nov 8, 2021

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
Copy link
Member

hlopko commented Nov 9, 2021

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
Copy link
Collaborator

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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

@hlopko
Copy link
Member

hlopko commented Mar 18, 2022

I'd say go ahead :)

@illicitonion
Copy link
Collaborator

Sounds very exciting! Go for it!

@UebelAndre
Copy link
Collaborator Author

@UebelAndre
Copy link
Collaborator Author

oh no! it failed 😞

@UebelAndre
Copy link
Collaborator Author

Going to try to recreate it.

@UebelAndre
Copy link
Collaborator Author

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

@UebelAndre
Copy link
Collaborator Author

@UebelAndre
Copy link
Collaborator Author

@UebelAndre
Copy link
Collaborator Author

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

@UebelAndre
Copy link
Collaborator Author

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

@UebelAndre
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants