OK, I will proceed with Domininik's or Zbigniew's idea. Thanks all to your
suggestions. :)
David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*
RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat <
;.
On Thu, Dec 1, 2016 at 9:13 AM, Pierre-Yves Chibon <pingou(a)pingoured.fr>
wrote:
On Thu, Dec 01, 2016 at 01:37:18AM +0000, Zbigniew
Jędrzejewski-Szmek
wrote:
> On Wed, Nov 30, 2016 at 05:35:19PM +0100, Dominik 'Rathann' Mierzejewski
wrote:
> > On Wednesday, 30 November 2016 at 16:07, David Kaspar [Dee'Kej] wrote:
> > > On Wed, Nov 30, 2016 at 12:38 PM, Dominik 'Rathann' Mierzejewski
<
> > > dominik(a)greysector.net> wrote:
> > [...]
> > > I'm not sure where your Version == 1.0 comes from. If they're
versioned
> > > > only by date now, then you have two options. Use Version: 0 in the
new
> > > > package in anticipation of upstream eventually reintroducing
semantic
> > > > versioning. Or, Version: YYYYMMDD. Admittedly, the latter looks
nicer
> > > > and upstream already said they'll stick to it.
> > > >
> > > The Version == 1.0 comes from the source code of the fonts
themselves.
> > > Running 'grep "Version" *.afm' tells me that there are
all files with
> > > Version == 1.0, except two of them (which have Version
> >
> > If they don't have the same version then it doesn't make sense to use
> > the version of *some* of them as base.
> >
> > > > If you worry about upstream versioning sanity, then stick with
> > > > Version: 0
> > > > and follow the snapshot versioning guidelines.
> > > >
> > > > > There's also one more option, and that is to base the
package on
> > > > > upstream's git repository and the snapshot scheme, because
we
> > > > > would be using snapshot string in the package name anyway. And
it
> > > > > would also solve one more issue that upstream is not shipping
> > > > > license files in the archive. (I have already contacted to
correct
> > > > > this.)
> > > >
> > > > The exact location of the source doesn't matter too much as long
as it's
> > > > official and pristine. I agree it might be better to use the git
repo
> > > > directly since it contains both the licence indication and its full
> > > > text.
> > > >
> > > Upstream has heard to my request and fixed it. (
> > >
http://bugs.ghostscript.com/show_bug.cgi?id=697390)
> > >
> > > And yes, what Douhlas wrote is correct (about the 35 fonts), and I
will
> > > have that noted in the %description section.
> > >
> > > Anyway, since determining the Version field is still unclear, I
think the
> > > most sense to me right now is to proceed with option 2) - IOW - to
bypass
> > > the versioning from URW++ completely, and have Version field based on
> > > snapshot string, in a way:
> > > X.Y.Z == YYYY.MM.DD
> > >
> > > Or do you some problem with this approach?
> >
> > As I said, please do not invent the version on your own. Please apply
> > the existing snapshot guidelines instead, i.e.:
> > Version: 0
> >
> > Release: 0.N.YYYYMMDD
> > or
> > Release: 0.N.YYYYMMDDgitHASH
>
> Or even better, as you proposed in the other e-mail, Version: YYYYMMDD.
> This is much nicer for users, and actually easier for the maintainer
> of the package. David seems to ignore this option for some reason,
> but it really seems the best one.
>
> (If upstream does something crazy and it is necessary to change the
> versioning scheme again in the future, adding an epoch is always an
> option.)
Since I guess the idea of this thread is to avoid using epoch, I think the
better approach is to stick with the Dominik's suggestions. It is what
gives the
most flexibility for future changes.
Pierre
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org