On Fri, Jun 19, 2020 at 8:19 AM Artur Iwicki <[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
