[meego-packaging] MeeGo Package Versioning (was Re: MeeGo package SR procedure)
david at dgreaves.com
Wed Jun 1 12:40:08 PDT 2011
On 01/06/11 15:46, Anas Nashif wrote:
> On 1 Jun 2011, at 00:42, Carsten Munk wrote:
>> 2011/5/31 David Greaves<david at dgreaves.com>:
>>> So now 1.2 is out I'd like to re-raise the 'changelog version' issue, ie:
>>> MeeGo package versions are not stored in the MeeGo changelogs (only upstream
>>> baseline versions).
>>> Information about a package version is primarily communicated via the
>>> The current policy does not accurately link the package/rpm version to the
>>> changelog entry.
>>> Given a changelog snippet it is not possible to determine which weekly
>>> release a bug is fixed in
>> (argh top posting)
>> So, we now have BOSS in the build.meego.com system. What stops us from
>> exporting delta meta data that includes delta of changelogs in
>> machine-readable form from previous version in places like
You could ... but I'd say changelogs are machine readable and are the
canonical form of expressing deltas against versions.
What we have now is a .changes file that is MeeGo specific and yetdoes
not map to a MeeGo-specific version - I appreciate that it made sense to
try this approach but I don't think it offers enough benefits for the
problems it causes.
So I'd counter with "why can't we use the widely used and proven method
of including the full version identifier in each changelog entry?"
>> In such a way that we collect data on in which release package changes
>> were made.
>> IE, a file containing that "in this release, we changed package source
>> versions from X to Y"
>> Our atomic recrd of a package release should be what is released on
>> repo.meego.com, IMHO. So we can pinpoint that "last change to source
>> package was in MeeGo release X.Y.Z", effectively tying the records
> isn't this already happening here:
> http://repo.meego.com/MeeGo/snapshots/stable/1.2.80/220.127.116.11.20110516.2/builddata/reports/ ?
And as a vendor Nokia had REVS. It was designed so that every time a
commit is made into Trunk it looks at the authoritative information (the
changelog) and puts it in a DB. It also takes every
image/release/snapshot and puts all those changelog entries into the DB
(again, it does the 'right thing' and uses the changelog as the master
>> Can you maybe specify some exact use cases we can help analyze?
The bug and original emails that I top-posted on had some.
Essentially I would like a *guarantee* that when I look at a changelog I
know exactly which rpm versions includes each of the changes mentioned.
More information about the MeeGo-packaging