Better handling of breaking changes

[sander2]

PR #330 made a breaking change, where the assumption of the use fee/tip handling pallet changed. This completely broke transaction signing for me, and unfortunately it took me some time to track it down to this change. Now technically, you didn't make a release, so maybe you wouldn't want to worry too much about breaking things. However, the last release was in march, so in practice people have to use the repo directly. In my case, I was forced to upgrade subxt versions because of dependency conflicts (although this was mainly because I was using the embedded client).

Anyway, my request is to think about a way to track breaking changes being made. For example, it would be a big help if such PRs and commits could be marked with a [BREAKING] tag or so. Or alternatively, to maintain an 'upgrading guide' where these things are listed.

[jsdw]

Perhaps we should start publishing the crate to crates.io (with suitably alpha ish version numbers). This would at least give us the mechanism to notify people of breaking changes via version numbers, and incentivise us to maintain a changelog that is kept in sync.

[dvdplm]

Yeah, I totally get that things are a bit painful atm. Our plan is to do proper releases to crates.io as James says. I'm not opposed to releasing alphas, but it'd be good to prepare a proper tracking ticket for what's in the next release and what isn't.

[ascjones]

Sorry about that, this was caused by a confluence of three things:

1. The current requirement for CI running against the latest substrate, which contained the updated TxPayment SignedExtension.
2. The Extra extrinsic data currently being hardcoded: Configurable extrinsic Extra  #331
3. The decision to actively develop the new version on master rather than on a separate branch (expect chaos).

We definitely need 2. before making any release.

I'm up for alpha releases, but I don't think we are there quite yet, First step is to make a list of the things we need to do in order to get there.

[jsdw]

We're getting into the flow of proper releases now, and hopefully also improving at signalling breaking chanegs in the changelog (we need to put more effort into the description at the top though). We also now have some milestones to at least give a vague idea of what's to come now.

I think developing on master is fine (now that we release proper versions especially). I'd be open to other suggestions on signalling things, but I think getting plenty of detail into the changelog now is the way to go.