Ongoing tagged releases?

[niloc132]

In 2019 a tagged release was made, but not all dependencies were marked with commit shas or tags, so this commit isn't buildable any more.

Recently another tag was added (two actually, but one promptly deleted), suggesting that there might be a "dated release" cadence that we could expect, as downstream users.

I'm excited to work off of these rather than picking a commit "at random" that seems recent and stable, to perform our own tag-and-release process, both to remove uncertainty about which commit to pick, and then to accelerate how often we update through that confidence (thus avoiding stumbling on long-fixed bugs). I held off on the first tag, anticipating that a month or so later a new tag might be released and a cadence established to set expectations, but as of writing there are still only the two tags.

Would it be reasonable to expect that these tags might be made monthly/quarterly/yearly, or should we expect some feature-based or stability-based significance to them as milestones rather than just time-based?

[gkdn]

Our intention is to have dated releases. Unfortunately we are currently lacking an automated process for that.
Being said that in this release we documented how to cut releases for all projects so I'm hoping that we can have more reasonable time frame between releases and eventually automate all of them to have them frequent.

In the meantime I added external item on issue tracker for J2CL tagging which is a good starting point: #209

[niloc132]

Checking back in on this - it looks like there have been a good number of passing CI builds since this discussion - would a manual release make sense in lieu of something automated?

Or perhaps did I misunderstand, and you're looking for something contributed from the community? I naively assumed that this wasn't the case from the bare-bones nature of the issue, but that might be a mistake on my part.

[gkdn]

We can do another manual release as a stop gap if it helps.

For the contribution, I was hoping something could be done via Github actions where we can periodically tag/release if build is green. I haven't looked into details but was hoping it is not complicated.

[niloc132]

It is nothing urgent on my part:

• The new jsinterop-base tag points to "master" rather than a tagged release or even a commit SHA. Historically this has made other parts of the j2cl ecosystem unusable from bazel, and I'm hoping to avoid it in the future.
  https://github.com/google/jsinterop-base/blob/a873215f2d62a5a054f5a79a36a768279093f054/WORKSPACE#L7-L11
• Given that the maven plugin uses some non-public APIs (just as the Bazel runner does), we're hoping for stability in versions/naming as in my initial post.

I believe a GHA job can be made to tag a revision, conditionally on what branch is being built on (in this cast "master"), after some other step has passed (such as in the existing ci job). Are there other criteria you'd like to see here for something user contributed? "First day of the month when a tag hasn't yet been created" may be possible with a custom action implementation (or a bunch of .sh code), but it is a bit beyond me - "passing nightly build should be tagged as vYYYYMMDD" though should be straightforward?

[gkdn]

I just checked. jsinterop-base release uses tagged release, not a commit as expected and master is using master.

Something like "passing build tagged as vYYYYMMDD" should be fine; we can schedule it weekly or monthly?

[niloc132]

My mistake, my rebase from 1.0.0 had the j2cl version pin, and it should have been dropped for 1.0.1 as you indicated.

I'll try in the next week for a PR to add a scheduled CI build that pushes a tag.