Skip to content

Feedback on switching from pre to bump #104

@cburgmer

Description

@cburgmer

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions