On 23/01/18 20:26, Tom Russo wrote: > 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? > I noticed the same issue as Dan on an IPv6 native host but didn't really want to comment until I had a chance to see if I knew what the issue was or solution might be (which I haven't). Its been running fine on my desktop in work since Last week. IMHO I wouldn't hold up a release because of it.
Regards John EI7IG _______________________________________________ Xastir-dev mailing list [email protected] http://xastir.org/mailman/listinfo/xastir-dev
