Make a pgloader release with CFFI 0.21.0

[phoe]

I plan on making an emergency pgloader release (3.6.1.1?, to avoid bumping the version number? 3.6.2, to actually bump the version number?) that has the same source commit as 3.6.1, but bumps CFFI to version 0.21.0 in the software bundle.

This is required to make pgloader buildable on SBCL 2.0.1 and newer, due to an incompatible change in SBCL 2.0.1 that CFFI worked around in 0.21.0 by cffi/cffi@375872a

That release will be uploaded to GitHub. It aims to fix #1087 and therefore avoid kicking pgloader off opensuse repositories.

To do so, I will need a blessing from @dimitri.

(If a standard software release will be done soon, please close this ticket - making an emergency release will not be required in that case.)

[svantevonerichsen6906]

What would be a censequence of bumping the patch version that you want to avoid?

[phoe]

This release is purely a bugfix one with no new functionalities or changes in source code. I am not decided whether that warrants bumping the patch version or not, and I am fine with going either way.

[msbsh]

As it does change the resulting artifact I would suggest reflecting it with an updated patch version.

[dimitri]

We are due to releasing 3.6.2 with the current source code in master anytime now. To do so, we need to build the bundle distribution and attach the resulting tgz file to the GitHub release, so that packagers can do their work. Do you want to have a look at it @phoe ? Meanwhile I'm trying to fix small bugs as I can.

[phoe]

Sure, I can take a look at that.

build the bundle distribution

What exactly do you mean by that?

[dimitri]

See https://github.com/dimitri/pgloader/releases and the assets available, and the make bundle target of the build system. It's a Quicklisp bundle with all our dependencies in there so that you can build the whole of pgloader from sources in a single archive file distribution. That's used to produce RPM packages. Debian chose to package all our dependencies instead, per the Debian user contract.

[phoe]

OK, working on it.

This requires bumping the BUNDLEDIST variable in Makefile to 2020-02-18. Otherwise, we run into the old CFFI version.

[phoe]

#1106 changes the QL dist version.

Attaching the created bundle to this issue: pgloader-bundle.zip (Sorry for the double-archive layer, GitHub doesn't accept TGZ files as attachments.)

[dimitri]

I could download the bundle you prepared and pass local tests with it. Looks good to me. It should be uploaded as “pgloader-bundle-3.6.2.tgz” in the assets part of the release on GitHub. You can make it a simple “bug fix release”, that's what it is after all, I don't think we have many release note worthy items with a quick look at v3.6.1...master. Maybe a note that DBF format received a lot of improvements.

[dimitri]

To prepare a release, don't forget to change https://github.com/dimitri/pgloader/blob/master/src/params.lisp#L43 and the version numbers in the Makefile too, and to tag the git repository with v3.6.2 too.

[phoe]

This now becomes non-trivial.

Do I need to change that param to t in the release commit and then immediately push another commit that sets this back to nil?

When am I supposed to bump the version numbers in params.lisp to 3.6.3, since the version there is already 3.6.2?

[dimitri]

Yeah that's right, exactly as you're saying:

1. change the param to t in the release commit that is going to be the v3.6.2 tag
2. make a follow-up commit where the release is back to nil and the *minor-version* is 3 already; then next builds will have either the git hash or be versioned 3.6.3~devel
3. publish the release on GitHub from the tag and attach the bundle file in which it's all version 3.6.2 (the resulting ./bin/pgloader --version is 3.6.2 there, and that's what I've seen on the previous try already).

[phoe]

The two commits have been pushed to master, along with the tag v3.6.2. A new bundle made from that tag is in a drafted release at https://github.com/dimitri/pgloader/releases.

Please review it one last time, and publish it once you're sure it's ready to go.

[dimitri]

Thanks a lot @phoe ! Everything looks good, and I did some manual tests with the bundle. I published the 3.6.2 release with all the bug fixes now. It would be awesome that we can do quarterly or even monthly releases someday ;-)

[phoe]

❤️

Thanks for the help! And thanks for a chance to make my first ever pgloader release.

This fixes #1087. Closing both issues.

[phoe]

As for more frequent releases, I see no issue with that. As long as there's releasable content, I know how to make pgloader bundles now.

I'll need to set up an environment for running the tests, or, better - I'll need to fix Travis to execute the tests for us. That's left for future work though.