[postgis-devel] PostgreSQL 9.5.0 has just been stamped

[Greg Troxel]

"Paragon Corporation" <lr at pcorp.us> writes:

> 1) PostGIS 2.2.0 will work with PostgreSQL 9.5.0 fine as far as my testing
> has determined and our bots do test against the 9.5 releases.

ok, so then there is no problem.

> 2) The rush is mostly since packagers I know like to get all things
> together, we just want to put our best foot forward and PostGIS 2.2.1 has a
> ton of bug fixes not present in 2.2.0.  
> We'd hate packagers packaging 2.2.0 instead of 2.2.1 when they roll out 9.5
> when we've put all this effort in 2.2.1

I don't see it that way at all.  packaging updates of postgresql and
postgis are independent, in my world.  And, postgresql breaks compat of
the db format on every major release, so pkgsrc maintains packages for
multiple versions, currently 9.1, 9.2, 9.3 and 9.4.

Adding 9.5 will happen in pkgsrc at some point, perhaps soon, but that
has nothing to do with when 2.2.0 is updated to 2.2.1.  In the pkgsrc
case, postgis can be built against any of the postgresql versions
(except ones which have been marked imcompatible, more or less).

When updating packages, minor updates along a branch that don't change
the ABI and don't signifcantly change the set of installed files are
nearly trivial.  The real work is adapting to upstream build system
changes, ABI breaks (for packages that have dependending packages), and
other structural changes.

The other thing about packaging is that it's not about having the latest
immediately.  It's about having a version that one can confidently
recommend as reasonable to people who want to run X but don't know how
to choose.  So while 9.5.0 might get added quickly, I definitely
wouldn't recomend anyone to start on it until it's been out for a while,
even if I think testing has been excellent.   I did update pkgsrc to
2.2.0 from 2.1.8, but I'm not sure that was wise.

To me, the more important consideration is not to rush the release
process, because that leads to releases with bugs.  It seems that might
have happened in 2.2.0, but that's certainly understandable in a
volunteer project.

> 3) I called for a planned release about 2 weeks ago and have been running
> like I'm live all this time and doing a lot of tests.  So this isn't
> something that we decided just yesterday.
> Granted the time frame between freeze and release could be longer (like we
> could actually freeze things), but not sure we are ready for that.  
> We aren't as big as PostgreSQL YET anyway in terms of devs and just
> mindshare to allow that luxury.

I did see about a release plan, but then just a few days ago there were
build system changes (which I think are right and which look
necessary).  That invalidates all the prior testing, and it needs to be
done again.  That's ok - the hard part is getting set up to test, not
testing, so doing an svn update and rerunning the test isn't that big a deal.

To get the benefit of testing/stability, you actually have to freeze
things.  There are a lot of people on the periphery who work on this
only once in a while as they are able.  So it's as simple as announcing
a freeeze, and waiting at least a week.  I don't see why that's a
problem -- people can still prepare changes for post-release and not
commit them.  <vcs-flamebait>If we had a VCS with branches that worked
well enough to be usable</>, those changes could be on branches.  If you
don't freeze, and release in a few days, then people won't get around to
testing, and casual testers will feel discouraged.  This is a typical
problem in open source -- the people who are close to the project do
everything fast, because for them this is the main thing.  People who
are on the periphery do not, but they bring a much needed diversity of
testing.

> 4) 2 outstanding changes left which I'm going to push to the next milestone
> if they are not fixed by tomorrow sometime
> https://trac.osgeo.org/postgis/query?status=assigned&status=new&status=reope
> ned&milestone=PostGIS+2.2.1&col=id&col=summary&col=status

Sure, deciding to push off changes to post release is totally reasonable
and necessary.  That's part of deciding to stop making changes, and to
only fix things that are regressions from the previous release which
really clearly cannot cause other problems.  Or to make a different
change and restart the release hold timer.

> Greg - if you could verify these 2 changes work for you that would be much
> appreciated:
>
> https://trac.osgeo.org/postgis/ticket/3390
> https://trac.osgeo.org/postgis/ticket/3415

Yes, I intend to, maybe tonight.  Basically I'll generate a release
tarball from the 2.2 svn branch, and use that to build pkgsrc instead of
the 2.2.0 tarball, basically doing a pre-update to 2.2.1 to see how that
goes, and can test that on NetBSD and OS X.  So you can see that this is
not a 5-minute process.  But I'd rather do it pre-release than post.

Presumably "make distcheck" is already known to work cleanly on a few
platforms.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20160105/e8f84cec/attachment.sig>