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.