FR: Add a revset to determine a set of commits which belong to a release.

[PhilipMetzger]

Is your feature request related to a problem? Please describe. Jujutsu is currently missing a way to identify a set of commits which belong into a release. As we primarily don't use branches to identify a set of commits, a revset should be used.

Describe the solution you'd like We should have a revset which determines which revisions are in a release, ideally the revset should make them immutable to only allow cherry-picked commits.

A solution could be some kind of globbing mechanism e.g glob(release/*) or some kind of template like release(2022-21-1).

Additional context This was previously hidden in #1431.

[thoughtpolice]

Do we really need something like this when the existing operator forms like x::y and x..y should more or less cover it? E.g. v0.12.0..v0.13.0 works basically perfectly for this, no? Assuming there is some abstract notion of 'tags' (which are pretty much necessary, of course.) Would release() have some kind of special behavior that these can't cover? I guess it could do some logic like release(y) = (x)..y where (x) could be some magical revset expression like "the previous tag", but tag naming conventions tend to be fairly project specific, so it's hard to know what that means.

Even if it was a pure alias, though, I feel there's a related principle at play here, where some things just aren't worth giving their own explicit name, if you can derive them easily and trivially from a pure set of combinators. In the Haskell community this idea is called the Fairbairn Threshold.

[thoughtpolice]

Also, there is a difference between "all the commits in release y" and "all the commits in release y that are not in release x.", (which is ::y or x::y more or less) and both are very useful. You may want to know if a release fixed a bug thanks to commit f (f & (x::y)) or if a release contained a security vulnerability introduced by a commit b (b & (::y)).

I think there are a lot of "general forms" here that could take shape depending on the structure of the project's releases and the specific query under examination.

[PhilipMetzger]

Do we really need something like this when the existing operator forms like x::y and x..y should more or less cover it? E.g. v0.12.0..v0.13.0 works basically perfectly for this, no? Assuming there is some abstract notion of 'tags' (which are pretty much necessary, of course.

Yes, we need something like it, as the above query is only applicable to a backend which has tags. I imagine Piper has its own ways and that counts for all other Git projects too.

Since there is such a wide variety of versions on how to define a release, I'd like the revset to be widely applicable. Ideally I'd only have to add it .jj/repo/config.toml and have the issue solved until I change my release scheme.

Would release() have some kind of special behavior that these can't cover?

The revset itself is not special. It only is a helper to make it easier to define some kind of version, be it semver with tags or some calver based branching scheme (which should be a revset in pure jj anyway).

I guess it could do some logic like release(y) = (x)..y where (x) could be some magical revset expression like "the previous tag", but tag naming conventions tend to be fairly project specific, so it's hard to know what that means.

Yes, that rather seems like the thing I had in mind 1.5 years ago (excluding any reference to tags though).

Even if it was a pure alias, though, I feel there's a related principle at play here, where some things just aren't worth giving their own explicit name, if you can derive them easily and trivially from a pure set of combinators. In the Haskell community this idea is called the Fairbairn Threshold.

I partially agree, it is nice that we can have combinators for it, but this does not save us from actually defining semantics for a native repo/pure jj future w/o taking all the semantics from Git or $FAVORITE_FUTURE_VCS, which definitely isn't my goal. And it ties into the future of the project, when Git no longer is dominant as we get a bunch of stuff for free from it now, which definitely could be gone in the future.

[thoughtpolice]

I suspect my question lies on an assumption: I think some sort of "nameable reference", be it called a tag or "release" or whatever by the native backend, in the glorious Jujutsu-future, is all sort of the same thing, I guess. :) So I suspect in a native backend we'd still have some way to refer to change IDs by another name, the same way we do now, so x::y is still applicable syntax. The v0.12.0 example is just one that works on this repository, not that we'd just copy Git tags wholesale.

Maybe Mononoke would be a good point of reference, since we could at least spelunk the code to maybe gather some insights ourselves.

[joyously]

If it's configurable, are you anticipating that configuring it is part of the release process? (I'm guessing no, because it would need to be meta data for the repo.)

Let's say you have this magical revset. When do you use it to restrict writing? How do you know if the person doing the release can write and others can't?

[PhilipMetzger]

I suspect my question lies on an assumption: I think some sort of "nameable reference", be it called a tag or "release" or whatever by the native backend, in the glorious Jujutsu-future, is all sort of the same thing, I guess. :) So I suspect in a native backend we'd still have some way to refer to change IDs by another name, the same way we do now, so x::y is still applicable syntax. The v0.12.0 example is just one that works on this repository, not that we'd just copy Git tags wholesale.

I never disagreed with that part :-), just with calling the concept explicitly "tags".

Maybe Mononoke would be a good point of reference, since we could at least spelunk the code to maybe gather some insights ourselves.

IIRC, Mononoke has bookmarks and that's it.

If it's configurable, are you anticipating that configuring it is part of the release process? (I'm guessing no, because it would need to be meta data for the repo.)

That's correct.

Let's say you have this magical revset. When do you use it to restrict writing? H ow do you know if the person doing the release can write and others can't?

I don't think thats of concern right now, ideally a jj-native forge would have something like ACLs which could allow you to restrict adding such a revset to a repository.