[Stk] New release and maintenance

[Felipe Sateler]

On 9 August 2016 at 13:28, Stephen Sinclair <radarsat1 at gmail.com> wrote:
> On Tue, Aug 9, 2016 at 1:17 PM, Felipe Sateler <fsateler at gmail.com> wrote:
>> On 9 August 2016 at 11:42, Stephen Sinclair <radarsat1 at gmail.com> wrote:
>>> I did a couple of diffs and found that the commit best matching the
>>> tarball is fb50d69e084.  (The one before the latest PR merge.)
>>>
>>> I did an annotated tag with the release comments and put the commit
>>> date back to Feb 22  (same as the commit.)
>>>
>>> Should be good now.
>>> https://github.com/thestk/stk/releases
>>
>> Please also retag with a different version number (eg, 4.5.1.0). It
>> appears I used the old tarball from github for debian, so we have a
>> faulty version. Debian does not allow using a different source package
>> with the same version, so we need a new number.
>
> Isn't the debian package version independent from the upstream version?
> There is the "upstream version" and the "debian revision"..
> http://www.fifi.org/doc/debian-policy/policy.html/ch-versions.html


A debian package consists of an upstream source + debian changes. The
upstream source is a tarball that is downloaded out-of-band by the
maintainer (in this case I pulled from github), and is uploaded to the
debian infra alongside the debian changes. To change the upstream
source, I need a new upsteam version, as there the 1-to-1 mapping of
version to tarball is enforced by the infrastructure.

If this can cause much confusion to your users, I can synthesize a
dummy version and use it only on debian.

> In any case you should treat this as having specified the wrong
> upstream URL in the package source.  (Since it should point at the
> CCRMA website.)  I assume in that case you would fix the URL and bump
> the "debian revision", without changing the "upstream version", so I
> don't see the problem.

I actually prefer the github tarballs, as they don't include stuff
that I will generate at build anyway. This generated stuff can then
introduce git noise in the packaging repository.

-- 

Saludos,
Felipe Sateler