[Xastir-dev] Long past time for a new release

[John Ronan]

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