[ACTION REQUIRED v4] Retiring packages for F-18

[Toshio Kuratomi]

On Thu, Jul 26, 2012 at 05:32:54PM -0700, Adam Williamson wrote:
> On Thu, 2012-07-26 at 19:52 -0400, Tom Lane wrote:
> > Jesse Keating <jkeating at redhat.com> writes:
> > > On Thu, 2012-07-26 at 15:37 -0700, Adam Williamson wrote:
> > >> The date is useful for making it
> > >> immediately obvious how up-to-date a package is, I guess, but it has no
> > >> really key function for differentiating builds any more.) 
> > 
> > > It's not even that.  With CVS you could have done a checkout of a tag
> > > which could be quite old compared to the day's date you did the
> > > checkout.  Using the date somewhat assumes you're doing a checkout of
> > > HEAD, which isn't always the case.  I'd move that embedding the date in
> > > there is of little use.
> > 
> > The good thing about putting the date in there is that it's likely to
> > help the NEVR sort correctly, whereas git hashes for instance will
> > certainly not help.  Upstreams have been known to change SCMs from time
> > to time, as well.  I realize we're supposed to bump the "0.n" part,
> > but I'd just as soon the upstream-ID part was likely to sort correctly
> > as well.
> 
> I really think the 0.n part is sufficient for this. You can always just
> bump it to avoid, really, any kind of difficulty. For example, the very
> case that prompted my aside: I just had to bump the 0.n part one digit
> to ensure that correcting the rest of the tag - which involved
> substantial changes, which would have ordered completely differently
> without the 0.n part - wouldn't cause any problems.
>
The Release tag serves multiple audiences.

For packagers and developers of the software, the revision id portion is
usually what we want but (as tgl pointed out) the date still comes in handy
if upstream changes their SCM.

For endusers, the date is more handy for seeing whether the package is based
on newer or older upstream versions than the scm's hash.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120727/8424d2d6/attachment.sig>