Does a 'safe harbor' release of the current HEAD make sense before further changes?

[alerque]

Per projectfluent/fluent#358 (comment), myself and @waywardmonkeys have recently been given permission to further development on this project. Many thanks to those inside Mozilla pursuing this outcome.

I'm opening this issue to invite discussion on the current release cycle. Frequently in the past when I have started maintaining a project that hasn't seen a release in a while, I'll cut a 'safe harbor' release that represents the current state of the repo with only minimal changes needed to make it releasable (e.g. changelog, etc.). This way anybody with concerns about an influx of code being stewarded under different management has an easy place to either pin their dependencies or audit the kind of changes that are being made. My question is does that make sense here.

There are not a *lot * of changes since the last tagged releases, but there are new features, bug fixes, and some minor refactoring that has landed under the guidance of the previous team. I haven't dug into them all yet to even know if this would need to be a semver patch or minor release if we were to make one, and whether the changes made to date are in a shippable state. I'll be looking at that, but if folks have input that would be great.

Next up after determining whether to pursue an immediate release of the current state will be reviewing the backlog of PRs and sorting out the state of existing contributions. Having been watching the PRs accumulate I know there is at least some good stuff in there! Then we'll start gearing up for future release cycles!

Thoughts?

[alerque]

Somewhat relevant to this: the latest fluent release on crates.io is 0.16.0, but this repository is missing the relevant tag is missing. It looks like b825cc3 should be tagged with fluent@0.16.0 whether or not we also do a new safe-harbor release. I'm refraining from adding the tag for the moment until I check out whether that is going to trigger CI stuff we don't want run far what is already a released crate version.

[eemeli]

All of the current CI stuff is only doing testing, and won't be triggered by adding the missing tag.

A safe harbour release does sound like a good idea, as it'll establish the transition more clearly.

[alerque]

Thanks for that feedback. I actually see there are a few other missing tags. I'm trying to track down for shure which commits got published and I'll address those.

But back to the main topic: I was trying to look into whether there are any semver "breaking" changes in the current Git HEAD (and hence whether the safe-harbor can be 0.16.1 or if it needs to be 0.17.0), but it is a little hard to check since tools like cargo semver-checks won't run at all since the last tagged release uses a version of self_cell where the entire series has been yanked! Deeper down the rabbit hole I go...

[alerque]

So the dependency on self_cell was only introduced between 0.15.0 and 0.16.0 ... but that does still mean 0.16.0 is currently not even buildable. Since the fix for that is in Git HEAD this brings even more urgency to a safe-harbor release! The previous published release isn't even buildable.

That being said the good news is there does not seem to be any semver breaking changes in HEAD since the last release except in the fluent-testing crate, so at least on that front we should be good to go for a round o patch level version bumps.

[alerque]

I've pushed tags for the most recently published version of each crate. I did not backfill old versions yet, but at least having the current versions tagged makes reviewing the changes that will be in a safe-harbor release and generating release notes easier.

Note besides missing tags there are anomalies as well. For example the existing fluent-ballback@0.6.0 tag is actually the 0.7.0 release. Some older tags are off-by-one from what is actually published to crates.io. I don't see any reason to delete the incorrect tags at this point "for historical reasons", just noting that if somebody actually wants to audit published crates they really should check what VCS commit it was actually built from.

[alerque]

@zbraniecki I don't want to be too pushy, but is there any chance this can get a poke? The whole thing is still hung up on one thing only you can do (add maintainers to fluent-langneg on crates.io) and one thing I could do myself I really think you should do (tag the current state of both repos and push to crates.io under your name so that there is no doubt that the safe harbor release doesn't contain anything subversive from new maintainers). The current snafu with xz-utils having been backdoored only adds to the importance and people might want to audit contributors more than ever. I have PRs prepared for all the crates with changelogs you can use and I've already run a bunch of testing so this should require very little work on your part. Merge the PRs, push a tag, cargo publish, and add me to the crate only you have access to. Pretty please? (I promise not to set any sock puppets on you for extra social pressure.)

[Xiretza]

Has anyone tried contacting @zbraniecki through other means? He doesn't seem to be reachable through GitHub.

[zbraniecki]

hi all, sorry for the radio silence. I'll try to take a look at this this weekend.

@alerque - would it be sufficient to share ownership with you for the projects that I'm the bottleneck on?

[alerque]

@zbraniecki That would help and if that's all you have time for then we'd take a statement to that effect as a sign to move on. I already have access to most of them, just not fluent-langneg. But I would strongly prefer if you actually merged the two PRs with release notes and did the cargo publish on the affected crates.

Other current/former members here have agreed a safe harbor release is a good idea and you doing it would basically just be signing off on the transition since you've done most of them to date. There are a couple years of unreleased commits here done under the original team's watch. When future releases are under a new name it should make it easer for people to review development work before/after maintainer changes. After you cargo publish the status quo (as I've summarized in changelogs for you already) we won't have to bother you for future releases (although you're be welcome around for sure).

[zbraniecki]

fair, thanks. Can you provide me STRs on what you'd like me to do? I'll execute over the weekend.

[alerque]

Sure here is the &str version:

• Add alerque to Owners on fluent-langneg.
• Merge fluent-langneg-rs PR#27.
• Checkout the main branch and make sure to pull the above merge, then cargo publish.
• Merge fluent-rs PR#349.
• Checkout the main branch and make sure to pull the above merge, then cargo publish. I believe this has to be done by iterating with -p <crate> through each crate in the workspace. I actually don't know off the top of my head what order that should be. I assume as you've done that before you'd know and I'd learn it from you, but if you want me to figure it out and report back I can.

I can even take care of the Git tagging to match the crates.io releases after the fact since there is no history of signed or even annotated tags, so there isn't a meaningful difference whether the tagging is done by you or me. In fact I already backfilled a bunch of missing tags in this repo for existing crate releases.

[zbraniecki]

@alerque I think I got it? There's a bunch of updates to be made, versions moved to workspace etc, but I think we got it!

I have my branches to move fluent-rs to use icu4x, and when I'm ready I'll push them as PRs for review :)