ought to be shown by apt-listchanges
(which shows you the top part of the changelog since the version being
upgraded from).
Simon Richter writes ("Re: d/changelog and experimental"):
> Bugs are closed based on the changes file, which is generated from the
> topmo
On Sun, 2019-12-08 at 23:24 +0100, Simon Richter wrote:
[...]
> The rest of the changelog only exists to preserve history. When you make
> an upload to experimental closing a bug, and you later upload the
> package to unstable, you have to close the bugs again in the changelog
> entry for
Hi,
On 08.12.19 22:29, Guillem Jover wrote:
> I think there are two important properties that need to be preserved
> so that debian/changelog entries keep making sense both for humans
> and machines alike. The first is that the parseable format entries
> should be sorted by version, otherwise
On 12/3/19 8:21 AM, Russ Allbery wrote:
> Paolo Greppi writes:
>
>> What is the best approach for d/changelog when releasing a package to
>> unstable after it has been through a few iterations to experimental ?
>
>> It would seem that the right thing to do is to keep all experimental
>>
Hi!
On Tue, 2019-12-03 at 08:15:19 +0100, Paolo Greppi wrote:
> What is the best approach for d/changelog when releasing a package
> to unstable after it has been through a few iterations to experimental ?
>
> It would seem that the right thing to do is to keep all experimental
> changelog
On Tue, Dec 03, 2019 at 09:53:43AM -0800, Russ Allbery wrote:
> Mike Hommey writes:
> > Well... I don't think there's anything good that can be done about the
> > entries about the unstable uploads that have happened in between...
>
> Yeah, that's true. Upload history is a graph and I have no
Hi,
On 03-12-2019 08:21, Russ Allbery wrote:
> Paolo Greppi writes:
>
>> What is the best approach for d/changelog when releasing a package to
>> unstable after it has been through a few iterations to experimental ?
>
>> It would seem that the right thing to do is to keep all experimental
>>
Mike Hommey writes:
> On Mon, Dec 02, 2019 at 11:21:12PM -0800, Russ Allbery wrote:
>> This is the typical practice, including all the intermediate
>> experiments or false starts in experimental.
>> I sympathize with wanting to clean up some of that, but as a project we
>> generally have
On Mon, Dec 02, 2019 at 11:21:12PM -0800, Russ Allbery wrote:
> Paolo Greppi writes:
>
> > What is the best approach for d/changelog when releasing a package to
> > unstable after it has been through a few iterations to experimental ?
>
> > It would seem that the right thing to do is to keep
Hi,
I think that every published versions must have an entry in d/changelog
If unstable version follows some experimental ones, then I prefer to have the
full entries.
This can also help to debug when an other package has a ">= exp-version"
Le 3 décembre 2019 08:21:12 GMT+01:00, Russ Allbery
Paolo Greppi writes:
> What is the best approach for d/changelog when releasing a package to
> unstable after it has been through a few iterations to experimental ?
> It would seem that the right thing to do is to keep all experimental
> changelog entries, and add a new one for unstable.
This
What is the best approach for d/changelog when releasing a package to unstable
after it has been through a few iterations to experimental ?
It would seem that the right thing to do is to keep all experimental changelog
entries, and add a new one for unstable.
But sometimes experimental
12 matches
Mail list logo
