We have not had an Xastir release since 2.0.8, prior to our move off of SourceForge and onto github.
That means that any package managers out there are providing code that's nearly two years old, since most won't generate new packages without release tarballs (and many won't do it even *with* new tarballs, but I digress). And those old packages probably all have READMEs and other documentation that points people to SourceForge. I'm thinking we ought to get to a nice stable place (maybe after all the IPv6 stuff is shaken out) and tag a new 2.1.0 release sometime soon. There have been a few notable improvements lately, and we should share them with people who aren't going to get all gitted up. I've already gone through the code and updated all the copyright dates, and cleaned up some documentation files in preparation for that sort of thing. Typically, a release under SourceForge meant Curt generated a post-boostrap.sh tarball of the code (so it includes configure and all the Makefile.ins), then just uploaded it. Generally, a release on Github is just a tag that makes it show up on the Releases tab, and then when a user clicks the ".zip" or ".tar.gz" link, github just zips or tars that repository state for them. It is possible to upload additional binary files to associate with release as well, but that's not what we want here -- we actually want the tarballs to be ready to configure/make, so the source tarball needs additional files. While it greatly simplifies the process of calling a repo state "released," that approach to release tarball generation makes the post-bootstrap.sh thing a little tricky. It has been proposed here before that we do it via a release branch, where we commit and push the bootstrap artifacts to the release branch, then just tag the head of that as the release, leaving master without those files. In that way, the release branch could just be checked out and built (without running bootstrap), as could any code taken out of a tarball of the release branch. I think I like that idea, and intend to make the 2.1.0 release like that if there are no objections to the approach. Anyone holding on to new code they'd like to see in the 2.1.0 release? Is Dan's experience with IPv6 addressing something that Jason is going to have to fix, and so should block doing the 2.1.0 release for a while? -- Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236 http://kevan.org/brain.cgi?DDTNM echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m] _______________________________________________ Xastir-dev mailing list [email protected] http://xastir.org/mailman/listinfo/xastir-dev
