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)
> Prereleases and Snapshots::
>
> I'm with tibbs in that I think snapshots should be considered
> postreleases, not prereleases.
The guidelines text is very clear that being a snapshot is orthogonal to
being pre or post :
« If a snapshot package is considered a "pre-release package", you
should follow the guidelines listed in Pre-Release Packages, and use an
%{alphatag} in the following format: »
Which is only sanity. If you're 99% of the way from release n to release
n+1 presenting it as n is very misleading.
The guidelines organisation unfortunately muddies waters a lot (if spot
is reading this please separate alphatag definition from actual pre and
post exmaples, right now it seems snapshots are the only form of post
release, and all the others are pre releases.)
> 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.
That's why good alphatags matter.
In this particular case the snapshot is getting more and more likely to
end up as the actual 2.7.0 (which is less than two days away) so I'd be
mad to declare it a 2.6.0.
Regards,
--
Nicolas Mailhot
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
