On Fri, Jun 19, 2020 at 8:19 AM Artur Iwicki <s...@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
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to