Hi dear mentors!

I'm the upstream author and Debian maintainer of a package, and after
uploading a couple of versions to different releases (unstable and experimental), now I'm unsure about what should be the *order* of the
different changelog entries in a forthcoming release to experimental,
I'm sure you'll be able to quickly solve my doubt.

Here is the order of events (from [1]):

[2021-01-03] Accepted mrpt 1:2.1.7-1 (source) into unstable
(New release, unstacle is frozen, so upload to experimental)
[2021-03-31] Accepted mrpt 1:2.2.0-1 (source amd64 all) into experimental
(Then we had to upload a patch to solve a serious bug in 2.1.7-1):
[2021-04-13] Accepted mrpt 1:2.1.7-2 (source) into unstable
Next, I want to release 2.3.0, into (I guess) experimental.

If I reflect the order of events above in debian/changelog, it would read:
mrpt (1:2.3.0-1) experimental; urgency=medium
...
mrpt (1:2.1.7-2) unstable; urgency=medium
...
mrpt (1:2.2.0-1) experimental; urgency=medium
...
mrpt (1:2.1.8-1) unstable; urgency=medium
...
mrpt (1:2.1.7-1) unstable; urgency=medium
...
mrpt (1:2.1.6-1) unstable; urgency=medium
...

Is it ok to have non-consecutive versions in the changelog? If not:
what's the correct way to handle it?

Extra question: How is a port from experimental to unstable supposed
to happen? Making a new upload with a new changelog entry?

Thanks!

[1] https://tracker.debian.org/pkg/mrpt

--

/**
* Jose Luis Blanco-Claraco
* Universidad de Almería - Departamento de Ingeniería
* [Homepage]( https://w3.ual.es/~jlblanco/ )
* [GH profile]( https://github.com/jlblancoc )
*/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Apr 25, 2021 at 09:37:49AM +0200, José Luis Blanco-Claraco wrote:

Hi dear mentors!

I'm the upstream author and Debian maintainer of a package, and after uploading a couple of versions to different releases (unstable and experimental), now I'm unsure about what should be the *order* of the different changelog entries in a forthcoming release to experimental,
I'm sure you'll be able to quickly solve my doubt.

Here is the order of events (from [1]):

[2021-01-03] Accepted mrpt 1:2.1.7-1 (source) into unstable
(New release, unstacle is frozen, so upload to experimental)
[2021-03-31] Accepted mrpt 1:2.2.0-1 (source amd64 all) into experimental (Then we had to upload a patch to solve a serious bug in 2.1.7-1): [2021-04-13] Accepted mrpt 1:2.1.7-2 (source) into unstable
Next, I want to release 2.3.0, into (I guess) experimental.

If I reflect the order of events above in debian/changelog, it would read: mrpt (1:2.3.0-1) experimental; urgency=medium
...
mrpt (1:2.1.7-2) unstable; urgency=medium
...
mrpt (1:2.2.0-1) experimental; urgency=medium
...
mrpt (1:2.1.8-1) unstable; urgency=medium

(I dont see that version on tacker… typo?)

...
mrpt (1:2.1.7-1) unstable; urgency=medium
...
mrpt (1:2.1.6-1) unstable; urgency=medium
...

Is it ok to have non-consecutive versions in the changelog? If not:
what's the correct way to handle it?

Extra question: How is a port from experimental to unstable supposed
to happen? Making a new upload with a new changelog entry?

Thanks!

[1] https://tracker.debian.org/pkg/mrpt

My bikeshed color on this would be not to order by date, but how the relations of the versions are; likw in anchestor/successor.

I mean, for example 2.2.0 never saw sid. So 2.1.7-2 is not based on 2.2.0, and following
the path, 2.3.0-1 is not based on 2.1.7-2, but on 2.2.0-1

IOW, I would order them this way:*

1:2.3.0-1
1:2.2.0-1
1:2.1.7-2
1:2.1.7-1
1:2.1.6-1


* There'd be a corner case when 2.3.0 is not based on 2.2.0, but thats unlikely (I didnt check)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2021-04-25 at 09:37 +0200, José Luis Blanco-Claraco wrote:

I'm the upstream author and Debian maintainer of a package, and after uploading a couple of versions to different releases (unstable and experimental), now I'm unsure about what should be the *order* of the different changelog entries in a forthcoming release to experimental,
I'm sure you'll be able to quickly solve my doubt.

What is the relation between the different versions?

If they are separate branches (2.1.X in unstable now to be replaced by
2.2.X currently in unstable), it might also be correct to just not
merge the changelog at all.

Otherwise it shouldn't matter too much as long as all changes in the
changelog happened (e.g., for all bugs mentioned as closed in the
changelog the relevant changes should be included).

There is `dpkg-mergechangelogs` in the dpkg-dev package which Git can
be configured to use to handle d/changelog; it will merge the
changelogs sorted by version number.

However that ordering is not always used: for example backported
packages will usually have a lower version as the top entry in
d/changelog (1.2.3-4 followed by 1.2.3-4~bpo11u1).

Extra question: How is a port from experimental to unstable supposed
to happen? Making a new upload with a new changelog entry?

Yes.

Ansgar

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks, Ansgar, Tobias, for the valuable feedback!

JL

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)