Changelog generation fails when version number is in unexpected format.

[Robert Bruce Park]

So this bug has bitten both jdstrand and sergiusens recently, whereby the changelog failed to find the tag and dumped 100 commits into the changelog message due to the version number being unexpected.

For jdstrand, he had a native package with native versioning, sergiusens had a version number like '1.12+bzr6858-0ubuntu2'

Here are the relevant branches:

https://code.launchpad.net/~jdstrand/click-apparmor/click-apparmor.lstat/+merge/210728
https://code.launchpad.net/~phablet-team/ofono/ppc64le-ftb/+merge/211152

[Robert Bruce Park (robru)]

In both cases, they had written their own debian/changelog, but citrain did not accept it at first, still overwriting it with huge stale commit logs. jdstrand isn't sure how he resolved it and sergiusens is still struggling with this as I type.

[Robert Bruce Park (robru)]

The code that causes this checks the destination branch for a tag with the version number present in trusty, and if it fails to find that then it just says "ok, I give up, I will include the most recent 100 commits". This is a pretty huge fail, if we can't find a correct resolution for this, we should instead say "ok, I give up, I will include only the most recent commit and ask the developer to write their own changelog entry."

[Didier Roche-Tolomelli (didrocks)]

I just bzr branch that branch. Did you try to do manually what cu2d is doing?

What i see is:
ofono (1.12.bzr6858+14.04.20140317-0ubuntu1) UNRELEASED; urgency=medium

  [ Dimitri John Ledkov ]
  * Correct ofono-scripts dependency on python3-dbus, not python-dbus.

  [ Tony Espy ]
  * src: fix build-failure on ppc64le arch
  * btio: fix build-failure on ppc64le arch

  [ Sergio Schvezov ]
  * Changing versioning to cope with citrain

 -- Sergio Schvezov <email address hidden> Mon, 17 Mar 2014 20:58:39 -0300

ofono (1.12.bzr6858+14.04.20140316-0ubuntu1) trusty; urgency=medium

  * Stub version for citrain

 -- Ricardo Salveti de Araujo <email address hidden> Mon, 03 Mar 2014 16:38:09 -0300

So, it's trying to find the latest release version:
1.12.bzr6858+14.04.20140316-0ubuntu1

When I bzr tags:
1.12+bzr6839-0ubuntu1 6839
1.12+bzr6844-0ubuntu1 6844
1.12+bzr6846-0ubuntu1 6846
1.12+bzr6848-0ubuntu1 6848
1.12+bzr6851-0ubuntu1 6851
1.12+bzr6856-0ubuntu1 6856
1.12+bzr6858-0ubuntu1 6858
13.10 6839
upstream-1.12+bzr 6831

I don't see that version. So it seems to me the behavior is exactly the one expected, right? (the fallback is trying to look in the commit log for "Releasing <version>" in case someone forgot to tag)

[Robert Bruce Park (robru)]

When did it start checking for "Releasing..."? The last time I looked at the code it said "can't find the tag, therefore show the last 100 commits", which is what I was seeing on both these projects at the time (they had to manually make changelogs to stop it happening).

[Didier Roche-Tolomelli (didrocks)]

Well, here the tag isn't there. So it's the expected behavior.

Then, it fallback to the last 100 commits and try to fetch here the "Releasing <version>" commit message and cut to that.
This is to transition from projects not having tag but being on daily release for instance.

Here, it's clearly an issue with the projects not having a tag, so doesn't seem to be a bug, right? It just missed the expected tag and thus, didn't find it.

[Didier Roche-Tolomelli (didrocks)]

ok, Sergio was able to give the exact configuration and this bug only reprocuded when:
- there was never CI Train nor daily release
- trunk contains changes with a changelog entry that was never released in destination
- the branch that we merge contains some changelog changes as well.

So, I added one additional fallback steps for that case (which is the intermediate one) to fetch from the latest version in distro if tagged in the branch (as it's in that case).
Changes deployed to production in http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/545