On Fri, 2006-06-16 at 22:22 +0200, Nicolas Mailhot wrote:
Le vendredi 16 juin 2006 à 12:52 -0700, Toshio Kuratomi a écrit :
> On Fri, 2006-06-16 at 20:53 +0200, Nicolas Mailhot wrote:
> > Le vendredi 16 juin 2006 à 13:21 -0500, Rex Dieter a écrit :
> > > Nicolas Mailhot wrote:
> > >
> > > > If the buildsys does not like ~, what separator could I use ?
> > > > I need to construct an alphatag out of svn number, svn date, svn
string
> > > >
> > > > For obvious reasons :
> > > > - svn number and svn date must be separated,
> > > > - the separator must be part of the base latin block
> > > > - - is taken as rpm field separator
> > > > - . is taken as in-field separator
> > >
> > > Despite your reservation about '.', that's probably the best
option.
> >
> > It seems plus (+) works, is easy to type and read, and is not already
> > taken (so no one will accuse me of breaking alphatag in multiple
> > fields).
> >
> > I now christen 'svnnumber'+'svndate'svn my official svn
alphatag.
> >
> > If no one objects and I remember how I'll put it in the wiki too.
>
> I object :-)
>
> I think the Packaging Guidelines are unclear, but really specify two
> separate cases:
>
> 1) This prerelease is a tarball. In which case it should carry
> upstream's chosen %{alphatag}:: dejavu-sfd-2.7.0-0.X.20060614-943
You really do not want to use "-" in rpm fields, trust me
> 2) This prerelease is a snapshot that has no upstream %{alphatag}, in
> which case you use DATEsvn: dejavu-sfd-2.7.0-0.X.20060614svn.
>
> Given that upstream is creating the tarball in this case, I can see
> either method being appropriate. However, I think mixing the two
> together should not become official policy.
It's not as clear-cut as this since upstream tarball is trivially named
after a SVN checkout, so your alphatag is a svn alphatag anyway.
Also the wiki example is very CVS-centered, in CVS you only have the
date to work with but with more advanced the date alone is meaningless.
Which is why they provide other means to identify a checkout (in svn's
case a number, in git case an hash, etc)
This has been discussed before. With the conclusion that DATES are
better than revisions in case upstream switches VCSs. I stopped being
lazy and actually searched for the post::
https://www.redhat.com/archives/fedora-extras-list/2006-January/msg00447....
mschwendt lists a solution which no one objected to... Use svn as the
delimiter between the DATE and the Release::
dejavu-sfd-2.7.0-0.X.20060614svn943
> It's rude to put upstream in the position of
> receiving bug reports about a non-existent version.
It's rude to put upstream in the position of receiving reports for bugs
in version N, when the user is actually running N + lots_of_changes, and
the problem is likely to be in the lots_of_changes_part.
When releasing a pre or post version you're *not* releasing the version
itself so *any* bug not specifying the pre or post will be rude to
upstream. Flattening out everything as posts won't help a little bit,
especially since you can't indicate any longer which real version you're
closest to.
Okay. I can see this view.
-Toshio