@progfolio @conao3 @jcs090218 @dickmao @adisbladis

As promised, here is a heads up about upcoming breaking changes. Originally I wanted to delay merging these changes, until the new version string scheme for snapshots is also ready, to avoid making breaking changes until some obviously exciting new feature arrives.

Finishing that will take longer to complete and even longer to be put into production than I had hoped, and it most likely won't involve any breaking changes, so I have decided to merge these breaking changes now. (Also merging this now will make testing easier, and since any version scheme update will require lots of testing, that is quite welcome.)

I expect these to be the last breaking changes for quite a while. In fact I cannot think of anything that would require breaking changes going forward, and some of these changes actively make future breaking changes less likely.

I plan to merge #66 and #67 in a week. Please try to make any necessary changes before then and be ready to merge them once I have merged these pull-requests. If you need more time, then please let me know.

67 contains all the commits from #66 because it depends on those. There are two pull-requests because I wanted the commit unique to #67 to be reviewed separately.

Breaking changes:

(This descriptions focus on the breaking effects of these commits. For the why, see the commit messages and pull-requests.)

964fdd043d2b49ebfeab793cb01582bdf4a3c3d8 removes package-build-expand-file-specs, which was deprecated in the last release. Yes, that isn't long ago, and I was prepared to keep it around longer, but given that there are other breaking changes, that doesn't make much sense anymore.
51e5ccd588fe9ce35b97b20582673e30b35a1515 Many low-level functions used to bind default-directory, making it impossible to override that without redefining each of these functions. Now that variable is bound in package-build--package and package-build--fetch (see later commits about the latter).
8377d6a1394dfc053057879efe533516b088335b package-build--run-process additionally loses the destination argument.
1136c4cbaeec3f8c7aeaec92e574327283c7632b Previously the recipe object that was passed around using function arguments only contained information about how to build any version of the package. Now we also store information about what version we are building in it. As a consequence many functions lose version and commit arguments.

If you use the affected internal functions, then you will have to adjust now. If you calculated, e.g., the version yourself and then passed it to an affected function, then you should be able to just use (progn (oset rcp version (your-calculation)) (the-function rcp)) instead of (the-function rcp (your-calculation)).

The nice thing about this is that it makes future breaking changes much less likely -- at the cost of a breaking change now.
ea2406f7dd31ddfb1d501a4e2af1d02564e231ca Clearly separates fetching, version detection and checking out. The functions that do those things continue to be considered internal, and if you use them anyway, then you likely will have to make adjustments now.

You shouldn't use these functions directly and if you do so anyway, then (1) you should let me know, (2) doing so should become easier due to this change (but is still discouraged).
0adc96b68147ef634b9bb45be57e76e3d60af229 Finally packages files specs in recipes get a bit more restrictive. See the commit to learn why we are doing that. This is a breaking change, but it likely won't affect you; in Melpa only three recipes had to be adjusted because of this.

melpa / package-build

Upcoming breaking changes #68

67 contains all the commits from #66 because it depends on those. There are two pull-requests because I wanted the commit unique to #67 to be reviewed separately.