search

girder / girder_web_components

Reusable Javascript and VueJS components for interacting with a Girder server.
https://gwc.girder.org
Apache License 2.0
16 stars 9 forks source link

Explore using semantic-release #236

Open subdavis opened 4 years ago

subdavis commented 4 years ago

@waxlamp suggested we use https://github.com/semantic-release/semantic-release for this project. I only really have 1 pet feature for a release system which is "it doesn't rely on pushing tags".

Looking at the docs, I'm not a huge fan of this caveat about the package.json version but maybe that's not actually a big deal.

subdavis commented 4 years ago

One other thought is that this only works if "push tag" and "do release" happen as a transaction and if one fails, the other gets rolled back.

zachmullen commented 4 years ago

I'm still not really on board with using in-band signals in commit messages to drive the release process. If others on this project want to use it, I won't object, but I'm personally not a fan. (To elaborate: using such tools forces your commit process to accommodate your release process, which strikes me as backwards.)

I actually like the tag pushing thing, since that seems like a much more natural integration between SCM and release. But that comes with its own set of headaches from trying to infer the version at packaging time.

waxlamp commented 4 years ago

Looking at the docs, I'm not a huge fan of this caveat about the package.json version but maybe that's not actually a big deal.

I also found this weird, but the alternative is to have some mechanism that can automatically create/push a commit with the version number change. It's essentially a choice between "weird but simple" and "follows tradition but requires a complex extra thing".

waxlamp commented 4 years ago

I'm still not really on board with using in-band signals in commit messages to drive the release process. If others on this project want to use it, I won't object, but I'm personally not a fan. (To elaborate: using such tools forces your commit process to accommodate your release process, which strikes me as backwards.)

I think this is true but only to a marginal degree. What I mean is, most of the time, the in-band signal is essentially metadata whose computation we're forcing (from the committer) at commit time. Something like, "please think about whether this is a feature, a fix, something else, and/or a breaking change right now". I generally find this to be beneficial. The analogy I made to @subdavis a little while ago was with typeful programming: there, you are taking on an upfront burden of specifying types, etc., in order to avoid a burden of debugging and code re-reading later on.

I believe this breaks down when special cases pop up. For instance, if you did make a mistake in annotating a commit, and now you need to deprecate a release because its version number ended up wrong, you have to cast an arcane spell to get things back on track (simple example off the top of my head: a PR with an empty commit with a feat: force a minor version bump type of commit message). Of course, this situation can come up when you're not using semantic-release too, and the process to fix things there will be equally ad hoc, but I'd argue that situation is worse: with something like semantic-release, at least you explicitly know you went out of bounds.

On the whole, I like the idea that releases stream out automatically, and then if I contribute a feature I can immediately use it downstream instead of having to engage the devs to create a hand-rolled release. I dunno. It's not objectively better or worse, but I do find it helpful on balance.

subdavis commented 4 years ago

Let's sit on this idea for a bit? So far, I've been happy with appending a "bump" commit onto my PRs. Roni could have added a commit to his original feature PR and we could have merged everything together, accomplishing the same goal.

The only trouble is that, in the rare event of a revert you have to remember to modify the version to increment from the last one.

GWC is relatively low-traffic, but if this starts to feel like a burden, we can revist. I only got PR-based released working like 3 weeks ago, so I'd like to maybe give the current style a fair shake.

zachmullen commented 4 years ago

I'm a big fan of every merge to master generating a pre-release. Maybe I'm old school but I still like to feel some sense of control over pushing non-prereleases, as they may confer some special level of stability beyond just a normal merge to master. Curious how others feel about this?

subdavis commented 4 years ago

I'm a big fan of every merge to master generating a pre-release

Yeah, that's completely fair. This would be nice to have.

Maybe I'm old school but I still like to feel some sense of control over pushing non-prereleases

Does opening a pull request not provide that sense of control? The thing that bothers me about tags is how it circumvents the whole git workflow and all the access controls you set up and makes releases a unilateral decision.

waxlamp commented 4 years ago

I'm a big fan of every merge to master generating a pre-release. Maybe I'm old school but I still like to feel some sense of control over pushing non-prereleases, as they may confer some special level of stability beyond just a normal merge to master. Curious how others feel about this?

I believe this would satisfy my immediate need of getting access to a published version in my downstream project.

On the topic of level of stability: the semantic-release philosophy is to just not worry about it, and use the exact version of the package that works for you. You'd only upgrade if there was a specific reason to do so (need a new feature; need a bugfix; avoid a security issue). "Stability" is supposed to devolve from being at a nonzero major version combined with an aversion to making breaking changes, but to be fair I've always used semantic-release with major version zero projects, so I've never experienced that "stable" regime.

These are just thoughts on the topic: I agree with GWC keeping the manual tag-push system to see how that feels for the core devs.

zachmullen commented 4 years ago

Does opening a pull request not provide that sense of control?

It really depends on our level of rigor in code review. When high-quality code review is a scarce resource, we often find ourselves rubber-stamping PRs with the notion that if something goes wrong, we'll fix it later. I liken this process to branch prediction heuristics.

I believe fairly strong that it's important for our latest non-prerelease packages to be stable and working, so if every PR merge is going to trigger an official release, I think it shifts the calculus of the per-PR review costs.