On 29 May 2015, at 11:41, Riccardo Mottola <riccardo.mott...@libero.it> wrote: > > Since we have an advanced make system,
Hahahaha! Oh, sorry, you were serious. > make dist, if you are on a quickie > make svn-tag && make svn-dist, if you want to do it nice. Okay, where does this upload the tarball to? Or do I now need to add tarball hosting to the requirements of a hosting provider as well? Oh, and this doesn’t actually do what I do (and what is best practice to do) to ensure a clean release tarball, which is tar up the result of svn export, to ensure that the tarball exactly matches the contents of svn. Instead, it deletes some files, hoping that it gets everything. If I run [g]make dist in something that is not a pristine checkout, then I get an incorrect release tarball. > Ah, and when I use cvs.... > make cvs-tag && make cvs-dist, really that different, isn't it? You’re missing the steps of uploading the tarball to the destination location. With GitHub, it is two git commands to go from a working branch to a release with public tarballs available. That just leaves sending the release announcement. > http://wiki.gnustep.org/index.php/Writing_Makefiles > > No need to launch a browser click on some web interface of github. None with GitHub either: $ git tag release_foo $ git push And now it’s done. The tarballs are online. The release is tagged, the tarballs are online, with a stable URL, and all I need to do to turn this into a FreeBSD package is change the release entry in the port Makefile into whatever release_foo was. > No need for a "hash", I have a version tag and I'm done. The hash is only required if I want to create a package from a non-released version. If I want to update a package from a release to an unreleased version (for example, if GNUstep used git now, I would make the packages include the fix that was found just after the last release by just setting the hash to use to the hash of that commit). It’s my fault for conflating two things here: 1) It is very easy to push out a release from a GitHub repo. 2) It is very easy as a packager *who is not necessarily a committer on that project* to create a package from a GitHub repo. If anything, the second of these is more important. Here is an example of a Makefile for a FreeBSD port of a GNUstep application that is hosted on GitHub: https://svnweb.freebsd.org/ports/head/devel/cherivis-devel/Makefile?revision=385521&view=markup If I want tup update this to a newer git revision, I need to modify two lines: PORTREVISION= 2 Becomes PORTREVISION= 3 This is internal to the FreeBSD ports system and is used to provide monotonicity in versions, even for unreleased code. The second line is: GH_TAGNAME= 525aeb4 This becomes the first 7 digits of the hash of the new revision (easy to find from either the git logs locally or via the GitHub web interface). Doing this update does not require the upstream (who, in this case, happens to be me, but pretend for a moment that it isn’t) to do a release. It just requires the packager to decide that they want to pull in a newer revision. Note that this Makefile is actually slightly more complex than most because it is packaging an unreleased version. Packaging the released version would not require the GH_TAGNAME entry at all, if the PORTVERSION matches the name of the release tag. After making these changes, the rest of the update is more or less automated. I presume that it’s similar for other packaging systems. GitHub goes out of its way to make it easy for packagers by generating (stable) tarballs from git versions and enough things are hosted on GitHub that it’s been worth providing some generic infrastructure to make packaging them easy on the FreeBSD side. David -- Sent from my STANTEC-ZEBRA _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
