A few days ago I adopted fritzing and fritzing-parts, which were orphaned by their original maintainer.
I looked at the package and at the upstream project and noticed a few things:
- Looking at the releases page for the app [1], upstream stopped doing releases manually and relies on a
  Continuous Delivery service. This is fine by itself, but at the same time, upstream switched to
  using the Continuous Delivery build ID as the main unique identifier for releases - and now there are
  two releases [2], [3] with the same semver. I suppose this may happen again in the future, so my thought was to
  use a combination of semver and the CD-build-ID as the Version: of the Fedora package, something like `0.9.4.CD498`.
- Looking at the releases page for the parts repository [4], upstream stopped bothering with git tags
  quite some time ago. The "build & release" script [5] that upstream uses just pulls the latest commit
  from the fritzing-parts repository when doing a build.

So now I'm just wondering:
1) Does the versioning scheme for the main package make sense?
2) For the fritzing-parts package, should I package the commit matching the official release
   (e.g. version CD-498 was released on 2019-12-01, so pick the 2019-11-24 commit from fritzing-parts,
   since that was "latest" at time of build), or don't care for synchronizing these and just go with the latest commit?
   The latter approach is easier, but I worry about potential backwards-incompatible changes.
3) For the fritzing-parts package, should I keep the semver and go with `semver-release.DATEgitCOMMIT`,
   or switch to `DATE-release.gitCOMMIT`? The latter option makes sense, but I'm not too keen
   about changing the versioning scheme.