[meego-packaging] MeeGo Package Versioning (was Re: MeeGo package SR procedure)

[David Greaves]

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
>>> changelog.
>>> 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
<snip>
>> (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
>> http://repo.meego.com/MeeGo/builds/1.2.0.90/1.2.0.90.0.20110517.1/builddata/
>> ?

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
>> together.
>>
>
>
> isn't this already happening here:
> http://repo.meego.com/MeeGo/snapshots/stable/1.2.80/1.2.80.2.20110516.2/builddata/reports/ ?

Yes.

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 
data source).

>> 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.

David