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
> > 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 <
> > > domi...@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
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.
devel mailing list -- email@example.com
To unsubscribe send an email to devel-le...@lists.fedoraproject.org