[postgis-devel] Getting PostGIS 3.0alpha1 super early

[Regina Obe]

> 
> 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] 
We can take out these interim releases on final release and warn people to upgrade to latest RC before we push out final release.

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.

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.

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.

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 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.


> > Absolutely no guarantees, no support for upgrade path, for the brave
> > who want it but can't install software without a version.
> 
> I'm not sure what's the issue that you are trying to solve with this.
> 
> If they don't need any guarantees or upgrade support they can use the
> standard autotools (./autogen.sh && ./configure && make install) and break
> their system as much as they want.
> 
[Regina Obe] 
I'm hoping we'll have some guarantee I mean testing upgrades is a HUGE deal and something we want people to do.
We should have some level of guarantee to at least say we'll try to fix any upgrade issues that arise, but still the caveate
"EXPERIMENTAL" 

> On the other hand, if the issue  is that they want distribution packages
> adapted to their needs, I don't like solving it by pushing an extra load to
> package maintainers by creating a premature tag [1]; specially considering we
> might end up modifying the build structure several times before the first
> release candidate.
[Regina Obe] 
It's really not much different than what PostgreSQL development does is it?
They say you'll probably have to do a dump /restore if using an alpha.

We won't be nagging maintainers and we never have we?  It's always a if you feel the need want to help test the tires.
We had lots of alphas in 2.0 cycle cause such major changes.