Bug#1137251: Package braa: Increment epoch in accordance with the Policy

On Fri, Jun 19, 2026 at 03:13:10PM +0200, Sven Geuer wrote:
> Hi Roland,
> 
> On Fri, 2026-06-19 at 09:20 +0200, Roland Clobus wrote:
> > Hi,
> > 
> > On 19/06/2026 09:01, Sven Geuer wrote:
> > > upstream's braa sources suffer from non-incremental version
> > > numbers:
> > > 0.82 < 0.9 < 0.9.1 according to the order of commits (don't rely on
> > > the order of tags displayed). The current packaging in Debian has
> > > version 0.82-7.
> > > 
> > > To be able to fix RC bug #1137251, I would like to increase the
> > > epoch to 1 and update the package to version 1:0.9.1.
> > 
> > You can change the version numbering slightly [1]: 'however, it may
> > need to be reformatted to fit into the package management system’s
> > format and comparison scheme.'
> > 
> > It looks like 0.82 was actually 0.8.2, so why not release 0.9.1 with
> > the reversed logic as '0.91+actually0.9.1'?
> 
> Thanks for your idea. On the other hand 0.82 fits the once apparently
> deliberately chosen numbering pattern [3] with even versions numbers
> 0.4, 0.41, 0.42, 0.421 (sic!).
> 
> > The package is at 0.x, so I guess there will be time to introduce
> > semver [2] version numbers until 1.x gets released.
> 
> Given upstream's sparse activities on braa, I feel not too confident
> that a 1.0.0 will be released even in years.
> 
> So, I still wonder whether bumping the epoch would be the appropriate
> choice in this case.
> 
> Are there other ideas?

Have you contacted upstream and asked them to cut a new release,
preferable following semver?


> > 
> > With kind regards,
> > Roland Clobus
> 
> Best,
> Sven
> 
> > 
> > [1]
> > https://www.debian.org/doc/debian-policy/ch-controlfields.html#version
> > [2] https://semver.org/
> 
> [3] https://web.archive.org/web/20100725000743/http://s-tech.elsat.net.pl/braa/
> 
> -- 
> GPG Fingerprint
> 3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585