Make a release

[Natureshadow]

I would like to package bucklespring for Debian.

It would be very helpful if we could get a stable (or beta) release tarball, or at least a version tag, for something that can be released as a working version. While simply packaging git master is kind of acceptable, it is far nicer to work with a real release.

Is the repo in a state that you'd call stable, or beta ready, right now? If so, would you be ready to give it a version number, and tag it (and probably provide a source tarball, but that would only be sugar on top)?

[zevv]

I would like to package bucklespring for Debian.

Woohoo \o/ Spread the noise!

Is the repo in a state that you'd call stable, or beta ready, right
now?

I guess so; I never really intended the toy to go public, but as far as
I know it runs good enough here. There's a number of things I can think
of that would make it better for the generic audience, but for now it
will do.

If so, would you be ready to give it a version number, and tag it
(and probably provide a source tarball, but that would only be sugar
on top)?

I just asked my doughter to throw a dice 3 times, we came up with
version number 1.3.3. Nice for a first label. Tag added to git, also
added a LICENCE file for the record.

Anything else I can help with?

[Natureshadow]

Kudos for dicing out the version number :D!

There is one thing. Could we remove the .exe from the repo? I cannot keep it in the source as per Debian policy because all binaries need to be re-creatable from source, which is not possible for the .exe with tools in Debian.

It seems it does not work correctly anyway, so could we just remove it upstream instead of having a diff in Debian?

[zevv]

• On 2016-09-16 19:27:01 +0200, Dominik George wrote:

There is one thing. Could we remove the .exe from the repo? I cannot
keep it in the source as per Debian policy because all binaries need
to be re-creatable from source, which is not possible for the .exe
with tools in Debian.

Definitely, it shouldn't be in there in the first place. Just removed.

:wq
^X^Cy^K^X^C^C^C^C

[Natureshadow]

If you now tag 1.3.5, everything is perfect to the point where you should get the upstream of the year award ;)!

[zevv]

• On 2016-09-16 19:46:10 +0200, Dominik George wrote:

If you now tag 1.3.5, everything is perfect to the point where you
should get the upstream of the year award ;)!

Lucky me, and it's only still September!

:wq
^X^Cy^K^X^C^C^C^C

[mirabilos]

OK, there are a few things still to be done before “that guy from the office across me to whom I delegated packaging it” can do that:

• the LICENCE file does contain the GNU GPLv2, but the code lacks an explicit licencing statement (which usually says “©”, the years of copyright (comma-separated, no ranges), the names of the authors, and the licence grant (such as “this is under GNU GPLv2”, possibly with “or any later version”)
• pedantic mode: do include a notice you recorded the waveforms yourself and publish them under licence X
• not so pedantic mode: what terms are those files under, and who’s the author (is it copied from libalure, or is this part of bucklespring)?
• these files also must go away from the source repository (well, the “source” in the name implies it)

Otherwise, great job!

[Natureshadow]

@mirabilos I have no idea about anyone delegating anything to me. But thanks for telling me what I can do and what I can't.

Apart from that, the binary libraries indeed would have to be removed as well. I do not agree with the rest, because the statement about the self-recorded wave files is actually there, the project-wide license file is sufficient - although, license headers within the source files would be nice to have. It is, however, in no way a blocking issue.

[zevv]

• On 2016-09-16 20:08:59 +0200, mirabilos wrote:

• pedantic mode: do include a notice you recorded the waveforms
  yourself and publish them under licence X

afaik these are simply part of the project, so the top level LICENCE
file applies.

• not so pedantic mode: what terms are those
  files
  under, and who’s the author (is it copied from libalure, or is this
  part of bucklespring)?
• these
  files
  also must go away from the source repository (well, the “source”
  in the name implies it)

'must' is a big word, it is still my repo. I understand these headers
and libs are in the way for an 'official' release, but simply removing
those is inconvenient to me, and possible others.

@Natureshadow: I could provide a official release tarball which I build
myself for each release, and leave out the win32 related stuff. Would
that do?

:wq
^X^Cy^K^X^C^C^C^C

[zevv]

Like this: https://github.com/zevv/bucklespring/releases/download/v1.3.6/buckle-1.3.6.tgz

[Natureshadow]

Well, let's start with documenting where these prebuilt static libraries (*.a) come from. Who built them? From what sources? That should indeed be documented, independent of the release tarball. Once we know that, let's see what should be done with them. Replacing them with their original sources would be the best solution.

Honestly, I do not like release tarballs that differ from the repo (except for VCS directories and control files) a lot, release tarballs should be reproducible from the git tag for the release. Mind that this is a SHOULD.

So, as said, start by telling where the *.a files come from ☺.

[zevv]

• On 2016-09-17 11:57:08 +0200, Dominik George wrote:

Honestly, I do not like release tarballs that differ from the repo
(except for VCS directories and control files) a lot, release tarballs
should be reproducible from the git tag for the release. Mind that
this is a SHOULD.

So, as said, start by telling where the *.a files come from ☺.

http://kcat.strangesoft.net/alure.html#download

But you're right, let's just throw them out. Frankly, I don't care about
windows myself, and if anyone wants to build, they are free to find and
install the libs theirselves.

Another thing: at this time the version number is configured in the
Makefile, but is also available as a git tag. This is one of the things
I always mess up. Would it be fine with you if I drop the one from the
Makefile, and have the makefile retreive this from git at build time?
(as I have just changed in current HEAD)

:wq
^X^Cy^K^X^C^C^C^C

[Natureshadow]

Why do you need it at build time in the first place? I do not think it is relevant for anything in this project, except for maybe printing it with -h or something. So just throw it out.

The Makefile must not depend on the existence of version control (and that is indeed a MUST NOT ;)…)

[zevv]

Why do you need it at build time in the first place? I do not think it
is relevant for anything in this project, except for maybe printing it
with -h or something.

Indeed, reason enough to keep it in. I hate it when it's hard to
figure out which version is running. Having the version number available
is essential for properly reporting bugs, etc.

[mirabilos]

Ico Doornekamp dixit:

Makefile, and have the makefile retreive this from git at build time?

git can’t retrieve it from a tarball now, can it?

bye,

//mirabilos

Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

[Natureshadow]

If you want to define the verion in the Makefile, then hard code it. Trying to retriev it the way you tried with git will break in the majority of cases - it works exactly when on a version tag in a clone of the git repo. It does not work on master, and it does not work from a source tarball, to name only two.

[Natureshadow]

I propose we close this bug, as it is getting mor eand more out of scope ;).

[zevv]

I propose we close this bug, as it is getting mor eand more out of scope ;).

Amen!