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

[Jason Godfrey]

I think I see the silly mistake that is causing that behavior - I don't
break out of the connect loop on success. I'll submit a fix, but it may be
a few days.

- Jason
On Tue, Jan 23, 2018 at 3:10 PM John Ronan <jpronans at gmail.com> wrote:

>
>
> 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
> Xastir-dev at lists.xastir.org
> http://xastir.org/mailman/listinfo/xastir-dev
>