On Fri, Jun 19, 2020 at 8:19 AM Artur Iwicki <suve(a)fedoraproject.org> wrote:
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.
I'm having to view the cached version of the version guidelines right now
due to the infra outage but something like:
<name>-<version>.<YYYYMMDD>CD<CD#>{%?dist}
??
Thanks,
Richard