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 <http://www.redhat.com/en/about/trusted>. On Thu, Dec 1, 2016 at 9:13 AM, Pierre-Yves Chibon <pin...@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 < > > > > 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 > > 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
