Skip to content

v2.0.0
Compare
Choose a tag to compare
@arp242 arp242 released this 30 Mar 00:36
· 512 commits to master since this release
v2.0.0
9200e53

The version is bumped to 2.0 because this contains a number of incompatible changes: several CLI commands got changed, and it includes some large database migrations – running them is a bit more complex than the standard migrations.

An overview of incompatible changes:

  • There are some rather large changes to the database layout for better efficiency; this means:

    • Somewhat faster queries.
    • Greatly reduced disk space requirements for the database.
    • The Browsers, systems, size, and location stats are filtered if you enter something in "filter paths". Previously this always displayed the site totals.
    • "Purge path" now works as expected for all stats.
    • Easier to add new statistics in the future.

    To update:

    1. You must first update to 1.4.2 and run all migrations from that. Updating from older versions directly to 2.0.0 will not work!

    2. Run the migrations with goatcounter serve -automigrate or goatcounter migrate.

    3. You probably want to manually run VACUUM (or VACUUM FULL for PostgreSQL) after the migration to free up unused rows. This isn't strictly required, but frees up disk space, and removes some of the autovacuum pressure that will run in the background.

    4. Run goatcounter reindex.

    All of this may take a while if you've got a lot of data. For about 500,000 pageviews it takes about 3 minutes on SQLite, but if you've got millions of pageviews it may take an hour or more.

    If you want to keep pageviews while this is running you can:

    1. Write it to a logfile from a proxy or temporary HTTP server and run goatcounter import on this after the migrations are done.

    2. Use goatcounter buffer.

  • goatcounter migrate is now goatcounter db migrate. It also behaves a bit different:

    • goatcounter db migrate pending lists only pending migrations, and will use exit code 1 if there are any pending migrations.
    • goatcounter db migrate list lists all migrations, always exits with 0.

  • If you use PostgreSQL you need PostgreSQL 12 or newer; this was already the case before and you could run in to some edge cases where things didn't work, but this is enforced now.

  • The none value got removed from the -tls flag; use tls=http to not serve TLS. This was confusingly named as you can do -tls=none,acme to still generate ACME certificates, but none implies that nothing is done.

  • goatcounter create is now goatcounter db site create, and some flags got changed:

    • -domain is now -vhost.
    • -parent is now -link.
    • -email is now -user.email.
    • -password is now -user.password.

  • The -port flag for goatcounter serve is renamed to -public-port. This should clarify that this isn't the listen port, but just the port GoatCounter is publicly accessible on.

  • The -site flag got removed from goatcounter import; you can now only use -url to set a GoatCounter site to import to. The automagic API key creation was more confusing than anything else.

    You can use goatcounter db create apitoken to create an API key from the CLI.

  • If you build from source, the build flag to set the version changed from:

    -ldflags="-X main.version=..."

    to:

    -ldflags="-X zgo.at/goatcounter.Version=..."

  • The CSV export format was increased to 2; it now includes the parsed browser and system values in addition to the User-Agent header. Version 2.0 will not be able to import the older exports from version 1.

Other changes:

  • You can read pageviews from logfiles with the goatcounter import command; you can also send pageviews to goatcounter.com with this (you don’t need to self-host it). See goatcounter help import and the site code documentation for details.

  • You can now create multiple users; before there was always a single one. You can add users in Settings → Users.

    As a consequence, "Site settings" and "User preferences" are now split in to two screens. The Settings button in the top-right now displays only site settings, and clicking on your email address in the top right displays user preferences, which every user can configure to their liking.

  • You can now configure what's displayed on the dashboard, in what order, and configure some aspects of various "widgets". You can set it in User preferences → Dashboard. Some settings from the main settings page have moved there.

  • You can save a default view for the dashboard. Instead of always loading the last week by default, you can now configure it to load the last month, or view by day, or anything you want really.

  • You can choose which data to collect; you can disable collecting any User-Agent, location, Referrer information.

  • Ability to record state/province/district in addition to country, so it records "US-TX" or "NL-NB" instead of "United States" or "Netherlands".

    This option can be disabled separately from recording the country (enabled by default) and you can set which countries to record it for (defaults to US, RU, CH).

    This requires specifying the path to a GeoIP City database, which isn't included since it's ~30M.

  • There are now stable count.v*.js scripts that can use subresource integrity. See the integration code for a list and hashes.

  • You can use data-goatcounter-settings on the <script> tag to load the settings (requires count.v2.js or newer).

  • New goatcounter buffer command; this allows buffering of pageviews in case the backend is down, running migrations, etc. See goatcounter help buffer for more information.

  • The database for PostgreSQL is now created automatically; you no longer need to do this manually.

  • You can copy settings from a site to other sites in Settings → Sites.

  • Add goatcounter db command; you can now edit and delete sites, users, and API keys from the CLI. The create and migrate commands are now merged in to this as subcommands.

  • Add a gcbench utility for inserting random pageviews in a database; for testing and comparing performance. This might be useful for end-users too in some cases, for example to see how much performance difference SQLite and PostgreSQL will give you, or to test if frobbing with server settings makes a difference:

    $ go run ./cmd/gcbench -db sqlite://db/gcbench.sqlite3 -ndays=90 -npaths=100 -nhits=1_000_000
$ go run ./cmd/gcbench -db postgresql://dbname=gcbench -ndays=90 -npaths=100 -nhits=1_000_000

    Right now it doesn't try super-hard to simulate read-world usage patterns: the distribution is always uniform, but it still gives a reasonably accurate indication for comparison purposes.

  • Many other minor changes and improvements.

  • For changes since RC1 see: v2.0.0-rc1...v2.0.0

Assets 5
Loading