fluster add epoch

[Christopher Obbard]

Hi!

For the package fluster, upstream at
http://github.com/fluendo/fluster/, we have a slight mistake with the
upstream versioning and I would like to add an epoch

The current version in debian is 1.0.1+git20231211.d9106f5-1 (since
upstream had released 1.0.1 but later deleted the tag) and now
upstream latest version is 0.2.0+git20250319.30ac3a8

I am proposing to add an epoch; e.g 1:0.2.0+git20250319.30ac3a8 to
make the mistakes from the past go away.

Does it sound OK to others ?

Cheers!

Chris

[Soren Stoutner]

On Saturday, March 22, 2025 1:09:29 PM Mountain Standard Time

Post by Christopher Obbard
Hi!
For the package fluster, upstream at
http://github.com/fluendo/fluster/, we have a slight mistake with
the upstream versioning and I would like to add an epoch
The current version in debian is 1.0.1+git20231211.d9106f5-1 (since
upstream had released 1.0.1 but later deleted the tag) and now
upstream latest version is 0.2.0+git20250319.30ac3a8
I am proposing to add an epoch; e.g 1:0.2.0+git20250319.30ac3a8 to
make the mistakes from the past go away.
Does it sound OK to others ?

Does upstream plan to release a 1.0.1 sometime in the future?

If so, I would probably go with a 1.0.1+really0.2.0 release until
upstream catches up.

Typically, I don’t like to go with an epoch unless upstream does
something that will never be compatible, like switching from a date
release of 2025-01-27 to 1.0.1.

[Christopher Obbard]

Hi Soren,

On Saturday, March 22, 2025 1:09:29 PM Mountain Standard Time

Post by Christopher Obbard
Hi!
For the package fluster, upstream at
http://github.com/fluendo/fluster/, we have a slight mistake with
the upstream versioning and I would like to add an epoch
The current version in debian is 1.0.1+git20231211.d9106f5-1 (since
upstream had released 1.0.1 but later deleted the tag) and now
upstream latest version is 0.2.0+git20250319.30ac3a8
I am proposing to add an epoch; e.g 1:0.2.0+git20250319.30ac3a8 to
make the mistakes from the past go away.
Does it sound OK to others ?

Does upstream plan to release a 1.0.1 sometime in the future?

I guess eventually upstream will release 1.0.1 but I don't think it
will be for a long while.
They had a few issues with their github release pipeline last year,
but all seems to be OK now.

If so, I would probably go with a 1.0.1+really0.2.0 release until
upstream catches up.
Typically, I don’t like to go with an epoch unless upstream does
something that will never be compatible, like switching from a date
release of 2025-01-27 to 1.0.1.

I am happy to do that rather than add an epoch; does anyone else have
any opinions ?

I thought an epoch would be cleaner here personally, but I don't have
any actual upstream Debian
packaging experience with epochs. When developing custom distros with
custom (not suitable for Debian)
packages we added them fairly frequently when bootstrapping things and
upstream changing things.
But it seems like adding epochs in Debian is a much more conservative
decision? It'd be interesting to
hear more about this, I possibly need some history lesson for
real-world case where adding epoch
is dangerous ;-).


Cheers!

Chris

[Carsten Schoenert]

Hello Christopher,

Post by Christopher Obbard
I guess eventually upstream will release 1.0.1 but I don't think it
will be for a long while.
They had a few issues with their github release pipeline last year,
but all seems to be OK now.

if you don't have statement from upstream about there future release
plannings it's just pure guessing what can happen.
Looking at the releases over time I don't have the impression it will
soon come to a release 1.x.

...

Post by Christopher Obbard
I am happy to do that rather than add an epoch; does anyone else have
any opinions ?

Post by Christopher Obbard
I thought an epoch would be cleaner here personally, but I don't

have any actual upstream Debian packaging experience with epochs.
When developing custom distros with custom (not suitable for Debian)
packages we added them fairly frequently when bootstrapping things
and upstream changing things. But it seems like adding epochs in
Debian is a much more conservative decision? It'd be interesting to
hear more about this, I possibly need some history lesson for real-
world case where adding epoch is dangerous ;-).

Yeah, epochs are for ever, and they confuse the "normal" users often as
they don't understand why they are in the version string.

So maybe another option is to introduce a new src and binary package
that can replace the existing package over time.

Looking at PyPi and into the pyproject.toml file the package seems to
have the real name 'fluster-conformance'.

https://pypi.org/project/fluster-conformance/
https://github.com/fluendo/fluster/blob/master/pyproject.toml#L6

So you could create a new src package with the name
'fluster-conformance' that is providing 'python3-fluster' and uses
Breaks/Replace and optional Provides for fluster.
Once you want to keep the binary name this all will not work because the
version issue plus package name is still the same then!

There is a wiki page existing about how to do some transitions of packages.
https://wiki.debian.org/PackageTransition

I haven't looked at all details so maybe my suggestion is also not
sufficient in the end and using an epoch is still the best solution.