On Wednesday, 30 November 2016 at 12:14, David Kaspar [Dee'Kej] wrote: > I took over the maintenance of urw-fonts to update them to the latest > version (ghostscript and other packages needs them). However, there are > several problems in versioning of it, and I would like to discuss future > steps for the package. > > The current problems: [...] > * we obtain the source archive from Artifex (aka upstream responsible for > ghostscript), nowadays they are no longer using the X.Y.Z versioning > system. Instead, they have created a separate git repository for it, and > are doing "snapshot based" releases... Their latest release is: > urw-base35-20160926.zip Do you mean this location? http://downloads.ghostscript.com/public/fonts/ > * I asked them if they could go back to X.Y.Z versioning system, here's > what Chris Liddell replied: > > "If you check the versions in the font files, you'll see why I switched to > the release dates. > For several releases they never changed from 1.10, and with the latest > release, they're back to 1.00. > Since this is how URW++ release them to us, there's not a huge amount we > can do." That makes sense. > * and as you can see above, they also changed the name from 'urw-fonts' to > 'urw-base35' because of this I also found this: http://git.ghostscript.com/?p=urw-core35-fonts.git;a=summary and they're called urw-core35-fonts here. It might be wise to ask upstream to clarify before choosing the new package name. > As you can see, the versioning of urw-fonts is total mess right now, and I > would like to bring back some order to it, but I don't want it to backfire > on me because of how URW++ tends to version their fonts... Here's my > proposed solution to this: > - create a new package for urw-fonts which would obsolete the current > urw-fonts > - choose a similar name to the new package - 'urw-base35-fonts' or similar Good idea, but see above. > And either... > 1) stick to URW++ based versioning - this would mean (at the moment) > Version == 1.0 and adding snapshot == 20160926 > (YYYYMMDD as described in > https://fedoraproject.org/wiki/Packaging:Versioning#Snapshot_packages) 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. > 2) or map the X.Y.Z versioning to YYYYMMDD from upstream - IOW - X == Year, > Y == Month, Z == Day (based on the snapshot date in the name of the source > archive) > 3) or set the Version to some constant (35 for example) and just use the > snapshot to distinguish between older and newer releases. What does the number "35" mean here, anyway? > I am affraid that I would pick option 1) it could pose problems in the > future again, because there's not guarantee that URW++ will follow sane > versioning. So, personally, I would choose 2) or 3). 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. I hope the above helps. You might want to review the current font packaging guidelines as well: https://fedoraproject.org/wiki/Packaging:FontsPolicy . Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
