Release 3.0.0

[jbeemster]

The current flat structure of the tracker means that irrespective we always import all the storage implementation libraries. This PR does some much needed cleanup and moves to a pkg structure so that the actual implementations of the interface need to be imported explicitly which removes the dependency on, mainly, sqlite3 (one of the more common forking reasons I have seen).

The API doesn't drastically change though it is breaking in one place.

The Emitter has a new function RequireStorage instead of OptionStorage as it must always be set now. The user must also either:

1. Define their own Storage implementation that matches the pkg/storage/storageiface interface OR;
2. Import one of our implementations explicitly and use the provided constructor to build the Emitter

---

Several structures that likely should not be used directly in the Public API have also been moved to the pkg structure and individually packaged to allow for this implementation. Hence name of branch is to set this as v3.0.0 given number of breaking changes.

This is the better way to build these sorts of libraries and makes it much more extensible for new implementations.

---

Release notes (example)

This is a major upgrade to the tracker with several breaking API changes. The main focus in this release has been to convert and move to a modular package structure. This lets us remove erroneous dependencies (like sqlite3 if we are using the memory storage implementation) but equally this is ensuring that only the required dependencies for the implementation are being brought in as the packages now need to be explicitly pulled.

Golang Version Changes

With this release we are now testing against Golang v1.19, 1.18 and 1.17. Versions older than this are not guaranteed to work anymore. Please let us know if you need the Tracker to work against older versions in an issue and we can consider investigating this.

API Changes

• tracker.InitPayload(): The Payload struct now cannot be imported from tracker and instead needs to be imported from pkg/payload to be initialized. The constructor has been renamed from InitPayload -> Init within this package.
• tracker.InitStorageMemory(): The StorageMemory implementation has been moved from tracker to pkg/storage/memory. The constructor has been renamed from InitStorageMemory -> Init within this package.
• tracker.InitStorageSQLite3(): The StorageSQLite3 implementation has been moved from tracker to pkg/storage/sqlite3. The constructor has been renamed from InitStorageSQLite3 -> Init within this package.
• tracker.Storage: For those that were providing a custom Storage layer implementation the interface now lives in pkg/storage/storageiface and contains the Storage interface and EventRow struct.

In the core tracker module the only interface change left is in the Emitter where OptionStorage and OptionDbName have been removed. You must now always provide a Storage implementation to the Emitter by:

1. Importing or defining a Storage implementation
2. Setting it with the RequireStorage function in the Emitter

As an example you can look at the below:

import (
  storagememory "github.com/snowplow/snowplow-golang-tracker/v3/pkg/storage/memory"
  tracker "github.com/snowplow/snowplow-golang-tracker/v3/tracker"
)

emitter := tracker.InitEmitter(tracker.RequireCollectorUri(collector),
  tracker.RequireStorage(storagememory.Init()), // ADD THIS
  tracker.OptionStorage(tracker.InitStorageMemory()), // REMOVE THIS
)

Other API moves

All helper functions used in the library have been moved from tracker to pkg/common. These were always intended for internal only usage so apologies if something you depend on has been moved!

[coveralls]

Coverage: 99.452% (-0.002%) from 99.455% when pulling feb869b35032da2428c2a52301c5c2e77de533d3 on release/3.0.0 into 9c10c8989a0acebad12099337d8806e22d8b9d60 on master.

[jbeemster]

@matus-tomlein @paulboocock any issues with merging this in? I can then take a stab at updating the docs to reflect these changes - I believe the release notes above cover the main themes and tbh most of the recommended API usage should stay the same even with all these changes.