Re: call for epoch (was Re: Bug#915553: ITP: pd-csound -- Csound external for Pure Data)
- Date: Tue, 4 Dec 2018 20:34:27 +0000
- From: Simon McVittie <smcv@xxxxxxxxxx>
- Subject: Re: call for epoch (was Re: Bug#915553: ITP: pd-csound -- Csound external for Pure Data)
On Tue, 04 Dec 2018 at 20:03:27 +0100, IOhannes m zmölnig (Debian/GNU) wrote:
> On 04.12.18 19:28, IOhannes m zmoelnig wrote:
> > Package: wnpp
> > * Package name : pd-csound
> > Version : 1.01.0
> > pd-csound used to be built from the csound (source) package, but upstream has
> > factored it out into a separate project (starting with fresh version numbers).
> > This is an attempt to bring the package back in.
> stretch features a pd-csound binary package built from "csound" with a
> version number "1:6.08.0~dfsg-1".
> upstream has factored out this component into a separate project (and
> therefore pd-csound is currently no more in buster), starting with a new
> version (1.01.0).
I would suggest talking to the upstream developer of pd-csound. It seems
reasonably likely that their users will be confused by the fact that
that version 1.01.0 of the "Csound external" (I assume that's some sort
of loadable module, analogous to a Python module?) is newer/better than
version 6.08.0 of the Csound external, despite its lower version number?
If they agree that this is confusing, they might be willing to re-version
to 7.01.0 or something, so that version numbers keep going up.
If they are unwilling to change the version number, then bumping the
epoch seems like a correct Debian-level workaround for the version
numbering scheme having been reset.