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@xxxxxxxxxxxxxx> 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.) Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
