Tag a release? about woff2 HOT 17 CLOSED

Seconding this.

@bramstein homebrew/head-only/woff2 has been removed. Perhaps you can submit your formula for it?

from woff2.

@Alhadis Nope because we need a tagged release. The formula is still available as homebrew/boneyard/woff2; once we get a stable release we’ll be able to move it in homebrew/core.

from woff2.

@bfontaine have issue to install using

brew install homebrew/boneyard/woff2

from woff2.

@FinalDes what is your issue?

from woff2.

==> Installing woff2 from homebrew/boneyard
==> Cloning https://github.com/google/woff2.git
Updating /Users/alex2/Library/Caches/Homebrew/woff2--git
==> Checking out branch master
Synchronizing submodule url for 'research/esaxx'
Synchronizing submodule url for 'terryfy'
==> make clean all
Last 15 lines from /Users/alex2/Library/Logs/Homebrew/woff2/01.make:
ar -t [-TLsv] archive [file ...]
ar -x [-ouTLsv] archive [file ...]
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar: illegal option -- f
usage: ar -d [-TLsv] archive file ...
ar -m [-TLsv] archive file ...
ar -m [-abiTLsv] position archive file ...
ar -p [-TLsv] archive [file ...]
ar -q [-cTLsv] archive file ...
ar -r [-cuTLsv] archive file ...
ar -r [-abciuTLsv] position archive file ...
ar -t [-TLsv] archive [file ...]
ar -x [-ouTLsv] archive [file ...]
make: *** [convert_woff2ttf_fuzzer] Error 1
make: *** Waiting for unfinished jobs....
make: *** [convert_woff2ttf_fuzzer_new_entry] Error 1

from woff2.

This is an issue with woff2; it uses the -f flag but that doesn’t appear to exist on macOS:

from woff2.

cc @mcatanzaro

from woff2.

@rsheeter Hi. Now that #92 has landed, it is possible to easily build a WOFF2 library or package it, for use in external projects (e.g. WebKit or Mozilla) instead of duplicating the source code. However, it is very important for these external projects to have a reliable reference commit their developers can use. For that purpose, adding at least some git tags or even github (pre-)releases would be very helpful (see https://help.github.com/articles/about-releases/). Would it be possible to do that or you think woff2 is not stable enough for such pre-release?

from woff2.

We are live in all the major browsers so ... probably it makes sense to just go ahead and designate a 1.0. I currently expect only bugfixes to this project, other than that it should be stable.

from woff2.

I've gone ahead and marked head as 1.0.0 (https://github.com/google/woff2/releases/tag/v1.0.0).

from woff2.

@rsheeter Thanks! However, I think you also need to update the version number in the cmake file so that it matches your tag number https://github.com/google/woff2/blob/master/CMakeLists.txt#L22

from woff2.

Well that's kind of annoying. I guess we're about to have 1.0.1 and I can easily see forgetting this in future. Don't suppose there is a standard way to have that be acquired on the fly rather than hard-coded?

from woff2.

We now have a 1.0.1

from woff2.

@rsheeter I'm not sure, but I guess the version has to be hardcoded somewhere in the source anyway (As a comparison, Brotli puts it in a separate header, which is parsed by the cmake file: https://github.com/google/brotli/blob/master/c/common/version.h). Maybe ask other projects how they manage it?

from woff2.

Users can get it from the tarball URL (https://github.com/google/woff2/archive/v1.0.1.tar.gz) but a lot of projects hardcode it somewhere so it’s printed on e.g. foo --version. I’ve also seen some projects use git during the build step to find the last tag and use it for the version.

from woff2.

It's important because it's going to go into the pkg-config file, so that projects that depend on libwoff can specify the minimum required version.

from woff2.

Users can get it from the tarball URL (https://github.com/google/woff2/archive/v1.0.1.tar.gz) but a lot of projects hardcode it somewhere so it’s printed on e.g. foo --version.

Right, if we want to fix #30 the version should be definitely hardcoded.

I’ve also seen some projects use git during the build step to find the last tag and use it for the version.

I'm not sure this is going to work well. We want to be sure about the version we build, not about the latest releases.

Well that's kind of annoying. I guess we're about to have 1.0.1 and I can easily see forgetting this in future.

I see two ways of improving this: 1) Add some release instructions and be sure to mention updating the version number in the process 2) Maybe do as in Brotli and put the version number in a separate file.

from woff2.