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.html
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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
