Release Engineering Meeting Recap from Monday 16-APR-07

[Thorsten Leemhuis]

On 17.04.2007 23:09, Jesse Keating wrote:
> On Tuesday 17 April 2007 17:01:11 Florian La Roche wrote:
>> I've suggested before to leave away the dist tag for the
>> devel branch completely and only add it for updates once a
>> release is put together.
>> This would be a change where packages now start depending on the
>> dist tag to identify certain releases.

Yeah, that would be nice, but....

> And I've shown you before where that utterly fails and completely misses the 
> usefulness of the disttag.

...I tend to agree with Jesse here.

> Either you have to fork all your specs between release and devel (which the 
> disttag is supposed to save you from doing) or you run into broken upgrade 
> paths were foo-1.3%{?dist} equates to foo-1.3.fc7 for F7 and foo-1.3  for 
> rawhide (F8) and you wind up with an broken upgrade path.

Well, why don't we just expand the disttag to something else without the 
"fc<I>n</I>" in it in the devel branch? A simple ".1" maybe -- that 
should make everybody happy afaics:

[thl at thl tmp]$ # this is how we do it right now:
[thl at thl tmp]$ rpmdev-vercmp 0 1.0 5.fc6 0 1.0 5.fc7
0:1.0-5.fc7 is newer
[thl at thl tmp]$ # why not do it like this:
[thl at thl tmp]$ rpmdev-vercmp 0 1.0 5.fc6 0 1.0 5.1
0:1.0-5.1 is newer

Or am I or rpmdev-vercmp missing something here?

/me always gets a bit confused when it comes to letters in %{release}

BTW, sure, the changelog entry and the actual release won't match fully 
this way, but that's the same with disttags.

Just my 2 cent.

CU
thl