On Mon, Apr 24, 2017 at 7:47 PM Rafal Luzynski <digitalfreak@lingonborough.com> wrote:

23.04.2017 19:23 Christopher <ctubbsii@fedoraproject.org> wrote:
>
> You can set the name of the file via the GitHub API when you download it.
>
> For jQuery (packaged as js-jquery), I use:
> https://github.com/jquery/jquery/archive/%{version}/jquery-%{version}.tar.gz
>
> This will work for any GitHub project which tags released versions:
>
> https://github.com/<user-or-group>/<repo>/archive/<tag-commit-or-branch>/<preferred-file-name>.tar.gz
> [...]

I'm afraid this will not work because (according to the GitHub
repo) this project has 0 release tags. Also the archive has been
created only 23 days ago. Isn't it too early to package a project
which has not yet ever been released upstream?

This also works for branch names, and commits, not just tags, as my later examples showed.

Whether or not it's too early to package... that probably depends on the nature of the software. Some projects work well with continuous delivery, but others (for example, those with well-defined, evolving APIs), it's probably better to wait on a release. You may be able to encourage the upstream project to create releases, if they know there's a downstream demand for them.

There's probably a wiki somewhere which explains how to do versioning in Fedora for continuous delivery projects, but I can't find it right now. It's probably something like:
Version: %{oneUpCounter}-%{shortcommit}
where oneUpCounter is incremented every time you update the package to a newer commit.
An alternative might be date-based:
Version: 20170424-%{shortcommit}
I'm not sure which would be preferred in Fedora. Hopefully somebody can link to some Wiki guidance.
(Of course, in either case, you'll probably end up having to bump the epoch if the project ever does start doing versioned releases.)