concourse / semver-resource

automated semantic version bumping
Apache License 2.0
97 stars 105 forks source link

Feedback on switching from pre to bump #104

Open cburgmer opened 4 years ago

cburgmer commented 4 years ago

Take this as user feedback. Ignore if you like.

I've tried twice now moving from {pre: something} to {bump: minor} or equivalent. The semantics are so different, and the feedback cycle so long (after all I cannot test this locally, can I), that this becomes a harrowing experience. I was only successful on the second try, which lasted a bit less than an hour.

Here is my attempt:

  1. Remove {pre: something}, after all I don't want this feature. (This fails, as there's no bump specified on put. There never was?? I guess pre is an implicit bump? Boo.)
  2. Add params: {bump: minor} to put, sure, bump something, I don't even need semver actually. (This fails, as the version bump happens in the wrong order, subsequent jobs consume a version that doesn't exist yet).
  3. Switch put to happen before steps consuming the new version (docker build). (This is bad as I am introducing unnecessary dependency on ordering and generating new versions even if the build fails.)
  4. Move the params: {bump: minor} to get. (This fails because put needs to put something, but doesn't know what.)
  5. Add params: {file: version/version} to put. Halleluja.

Yes, this is the first example in the README, but I spent most of my reading on the latter "API" docs which all call out the params block to be optional, which isn't really true now, is it.

If you agree that software should be simple and intuitive, you might want to follow up. I'm happy to provide more details if you do.