On Fri, Jun 19, 2020 at 8:19 AM Artur Iwicki <suve@xxxxxxxxxxxxxxxxx> 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
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
