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