Include binary packages for the latest release on the release page

[davelab6]

@frank-trampe has uploaded a new src tarball and RPMs to https://github.com/fontforge/fontforge/releases/

Everyone, please check these files and let us know here if there are any critical mistakes.

• @monkeyiq please make a mac build :)
• @jtanx please make a win build :)
• @frank-trampe please make the .deb related files
• @frank-trampe please put the deb files in a PPA
• @frank-trampe please put a description of how to install on Ubuntu using the PPA on the release page
• @frank-trampe please put a description of how to install on Fedora using the repos.fedorapeople.org repo on the GNU+Linux page
• and link to that on the release page

[frank-trampe]

All of the Debian binaries are in the Launchpad repository.

[davelab6]

Still, please add them to the release page at https://github.com/fontforge/fontforge/releases

[jtanx]

32-bit Windows build done

[DomT4]

I'll bump this over at Homebrew later today.

[DomT4]

Homebrew.

[DomT4]

Question: Is this a pre-release or a latest-release build? It's tagged "Latest Release" in the Release page, but you've tagged this issue pre-release?

[adrientetar]

@DomT4 Consider it a release. :)

[DomT4]

@adrientetar Thanks! Any idea why I'm getting the no install.sh message here?

[adrientetar]

No… cc @monkeyiq

[davelab6]

Still, please add them to the release page at https://github.com/fontforge/fontforge/releases

I spoke to @frank-trampe about this and its better to have a link to the PPA on the release page. Added task to top of this issue

I also asked Frank to make a PPA-style repo at http://fedoraproject.org/wiki/Fedorapeople_Repos . Added task to top of this issue, too.

@monkeyiq , hmm, on fuuko there is a build from 10/7 at 98Mb (.zip), and a build from today 10/15 which is 76Mb (.zip) - why the big drop in filesize?

[davelab6]

@frank-trampe you included a link to http://fuuko.libferris.com/osx/packages/201410/07_1052/FontForge.app.zip on the release page, but that obvoiusly predates the release. I've removed the link now. Let's wait for @monkeyiq to respond the file size drop before adding a link to the mac package.

@frank-trampe also, you've uploaded a tarball -
https://github.com/fontforge/fontforge/releases/download/20141014/fontforge-20141014.tar.gz - but how is that different to the automatic tarballs made - eg https://github.com/fontforge/fontforge/archive/20141014.tar.gz - which are grey buttons on the https://github.com/fontforge/fontforge/releases page? Please describe that on the release page too.

[davelab6]

Using Mac 10/15 build, I go to the Tools menu, start Web Server in Collab More, and I see:

And indeed, there is no Collaborate menu item on the menu bar:

So seems this feature which I thought is now a core feature (with zeromq etc as required dependencies) is missing.

[frank-trampe]

The source tarball is for building Red Hat packages. It includes some prerequisite files not checked into git.

[DomT4]

https://github.com/fontforge/fontforge/releases/download/20141014/fontforge-20141014.tar.gz - but how is that different to the automatic tarballs made - eg https://github.com/fontforge/fontforge/archive/20141014.tar.gz - which are grey buttons on the https://github.com/fontforge/fontforge/releases page? Please describe that on the release page too.

A big size difference, and the release tarball seems to contain a pre-built ./configure script whereas the Github-automatic tarballs need to undergo a ./bootstrap.sh first.

[davelab6]

@DomT4 @jtanx Thanks so much to you both for the quick turnaround on this! :)

The source tarball is for building Red Hat packages. It includes some prerequisite files not checked into git.
...
A big size difference, and the release tarball seems to contain a pre-built ./configure script whereas the Github-automatic tarballs need to undergo a ./bootstrap.sh first.

Ah yes, I see - in git master the ./configure and other pre-req files are generated by bootstrap after pulling down 3rd party files from the net, which isn't possible when using common build services. Lets note that on the release page.

[davelab6]

@frank-trampe The previous release was versioned as "2.0.20140813" but this is "20141014" - why did you not use 2.0.20142014?

[davelab6]

@frank-trampe do you think many people will want to download only specific RPMs? I think it might be nicer to just have 1 large ZIP with all the RPMs in it.

[frank-trampe]

We still expect anybody building from the release tarball to run bootstrap when possible. There are other things like gnulib (which is responsible for most of the data) and certain typeface samples that motivated the creation of an extended release tarball (as built by ./bootstrap; ./configure; make deb-src; ).

I misremembered how we had tagged the previous release, or it changed somehow. I was looking at the Launchpad builds, and we used the date-only name there consistently. I don't know how that would be different from the GitHub tag.

The R. P. M. posting, if a bit cluttered, is only temporary. Once we have a real repository server, we can direct people to use that.

[adrientetar]

why did you not use 2.0.20142014?

Rubbish redundancy is what comes to mind. "2.0" is useless if we don't increment it and it makes more sense to use dates since we're more on a rolling release model.

[davelab6]

@JoesCat what was your motivation for this numbering scheme? I have a hazy memory that without it Debian or some other distro couldn't cope with date based version numbers...

[davelab6]

@monkeyiq has posted a new mac build and I've attached it to the release page, with the collaboration (theoreticall) working.

[skef]

This happened.