[postgis-devel] Getting PostGIS 3.0alpha1 super early

[Greg Troxel]

"Regina Obe" <lr at pcorp.us> writes:

>> As a developer it's a pain when I try to upgrade a dev cluster and every
>> database has a different Postgis version even though they have exactly the
>> same SQL code, e.g. `2.5.1dev--3.0.0dev`, `2.5.1dev--3.0.0alpha1`, `2.5.1dev--
>> 3.0.0alpha1dev`. Having unnecessary releases doesn't help.
>> 
> [Regina Obe] 
>
> Take your developer hat off for a minute.  There are lots of great
> testers out there who may not be setup to compile but will happily
> test out alphas and so forth and find lots of issues and will even
> test with production data.

I am certainly not going to package an alpha.  pkgsrc norms are to
package actual releases, so people can use them.  There is a place where
we have bleeding edge packages - but there are no binary builds of those
- it's a way to share in-progress packages.

> Packagers don't like releasing non-tagged versions cause it's hard to
> keep track what point in time that was.  I know I don't. Saying at
> fixed stopping points at 3.0alpha1 has this thist and that etc is way
> easier than remembering r12345 or git abceeeeee I tend to keep those
> alphas aside so I can retest them because I know they are points in
> time when we are not in the middle of a broken build.

Sure, but I don't see the point in packaging an alpha.  ( It is less
bothersome than packaging a random revision without a tag.)

> So I think you will find some packagers especially those that are
> packaging the PostgreSQL 12 alpha will be happy to release a tagged
> 3.0alpha alongside.  I could be wrong though.  At anyrate we might
> want to wait til PostgreSQL 12 alpha comes out.

I do like alpha/beta as a packager.  But the point is to update locally
to them, to see if there is anything new/wrong/different and either
complain or adapt as appropriate, to not have surprises later.  This has
value when things are getting sort of close.

> My only hesitation is the possible expectation that 3.0 will come out
> at same time at PostgreSQL 12.  We hadn't planned for that, though
> given how much we've changed already, it's possible.

I think people need to stop expecting postgis releases to be in sync
with pgsql releases.  The world is complicated enough without adding
constraints like this.  It's easy to have a new point release to add
support for some new pgsql version later, without more serious changes.

> I also like these pre-releases as kind of a dress rehearsal especially
> for major releases like 3.0.  We are definely going to have an alpha
> at some point.  Whether December is too early is only question in my
> mind.

Agreed.

So what is the expected timeline of first alpha, first beta, first rc,
release?  Are we in feature freeze?  Or a list of feature changes that
are allowed, and others aren't?  To me, the big thing is to have an
overall release plan, not to talk about if it's alpha time.  I have no
idea if we are talking 1 month or 6, just a memory that releases are
often surprisingly rushed....


Getting testing by people that can't build from source is IMHO too hard
(because it requires not only alphas/beta/rc but also packaging them and
distributing binary packages).  It seems like it shouldn't be that hard
to build and if it is, that could be addressed.