v4.0.0

Unfortunately this is a major version w/o a lot fun inside :) Anyway I thought about it and IMHO worth the major bump in order to raise your attention about why this release could break something.

The only and interested commit is

• 252ec90 Hooks raise when their command exits with error

Follow the commit link to read full (?) explanation. But here it is the short one: if you relied on hooks chain in your movefile.yml having a hook exiting with error (a failing hook) before Wordmove just logged the fact and continued its work while now Wordmove logs the fact and exists throwing an exception (so w/ a non-zero exit code).

So as far as it is formally a backward compatible new behavior, we can't risk to let you update production environments or CI/CD servers without a little warning and attention.

The change is introduced because:

• hooks should be more CD-oriented and so every step MUST be "green" before continue
• this way you can rely more on the order relation between hooks (a must be completed successfully in order to run b; before it was not possible)
• you can break long hooks like a && b && c into single, more readable hooks

    - 'a'
    - 'b'
    - 'c'

obtaining the same behavior as using bash's && operator.

• if you have a lot of hooks or really verbose ones (webpack builds anyone?) now Wordmove will blow up and you certainly will notice the problem. He had a real life experience where we trashed half an hour of work and useless debugging before noticing webpack was no more compiling the production build correctly! 👿

What should I do if I'd like to have optionally failing hooks?

My advice is to wrap your maybe-fail hooks in little shell scripts and manage from there the return status (explicitly exit 0 at the bottom would be enough in most cases)

Future improvements

• Support maybe fail hooks through configuration
• do not blow up with stack trace, but rescue with an informational message and/or...
• chat notifier on success/failure