Question: when will first release version be released?

[evan0greenup]

Question: when will first release version be released?

Is there a milestone for version 0.0.1 to be released?

[ndmitchell]

We are using Buck2 at Meta for thousands of developers, so consider it quite far advanced already. I'm not sure we have any plans to cut an official release, we typically use the latest version, so consider it always ready to go. We might want to put some stability guarantees around a specific version in future, but hadn't thought about that.

Perhaps asked a different way, what are you hoping to get out of a release?

[thoughtpolice]

While this sounds strange at a glance, I think stuff like this is actually a cultural difference between a place like Meta and most consumers of FOSS projects.

From the point of view of a downstream FOSS user, like, someone who is interested in buck2 and what it can do, this question could be re-phrased through multiple lenses:

• Where do I, a user of prospective project foobar, get a buck2 binary, when I want to build foobar from source?
• Where do I, as a person interested in buck2, keep up to date with changes?
• What version of buck2, do I, a package maintainer, include in my repository for downstream users who don't compile themselves? (For example, NixOS in the case of yours truly)
• What do I, the developer of a project using buck2, look for when I want to see what's changed or introduced or been changed in the API?
• What do I, the developer of a project using buck2, need to know about the relationship between buck2 and buck2-prelude and the dependencies between the two?
• And so on and so forth

Broadly speaking, all of these questions can be put under the umbrella of "release management." People want releases because they directly relate to or answer all of these questions. Release management helps define how APIs can break, what releases users should use (stable vs prerelease), and much more. Proper release management for a project needs to answer questions like this to satisfy users.

However, at a place like Meta or any company, basically none of these apply. You have a team focused on providing buck2 binaries, so users don't need to care. The version of buck2 and buck2-prelude is irrelevant, because they can be updated atomically as rollouts happen, and backwards compatibility is irrelevant as changes can simply be done in a three step process (add new thing, migrate users of old thing to new thing, delete all uses of old thing). So all of this is answered ahead of time by policies that already exist.

I have a similar setup with buck2-nix: I migrate the buck2 binary and all of my rules atomically at once, so releases are not important for me in that regard. I control the whole pipeline, so it's easy to see what changes are needed. That said: I'd still benefit from releases, because they answer questions like "What new APIs are there?" Reading git history is a bit of a chore!

I could write more about this, but I think this is long enough to chew on for the team. Bi-monthly git tags and binaries being cut, even if a policy isn't fully figured out, might be a good place to start...

[ndmitchell]

Thanks for the notes @thoughtpolice - hopefully binaries are being solved in #113. But that still leaves plenty of discussion points left! I'll encourage members of the team to post their thoughts here.

[kaniini]

Perhaps asked a different way, what are you hoping to get out of a release?

Releases help interested parties, such as curators of FOSS distributions, to distribute your software to their downstream users. Without them, we have no knowledge of which commits of buck2 are related to a stable version that we should recommend to our users.

[ndmitchell]

We now have released binaries with tags every 2 weeks. We have 6 of them, so I think this ticket is done. Anything else required?