[postgis-devel] PSC Vote: Next release after 2.5 minor series will be 3.0

[Regina Obe]

No No :)

 

3.1, 3.2 will not be maintenance releases.  They will have new functions etc, as we always have done and micros will continue to be maintenance releases.

 

What we lose is we have to guarantee that the minors do not drop C functions used by the previous minors SQL API so it's safe to do a pg_upgrade without installing a previous version or linking to a newer version.

 

4.0 can have breaking changes – only promises to be backward compatible with 4s.

 

I expect each major to carry us 5-10 years.

 

I think aligning with PostgreSQL #s will cause more confusion than help unless we want to go down the path of each version of PostGIS only supports one major version of PostgreSQL.

A battle even if I agreed with it I know I would lose, so not going to bother even attempting it.

 

 

 

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Darafei "Kom?pa" Praliaskouski
Sent: Monday, July 09, 2018 4:18 PM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [postgis-devel] PSC Vote: Next release after 2.5 minor series will be 3.0

 

 

3.0 after 2.5 this September: sure. let's break all the things! :) 

 

Version: think not only upgrades but (accidential) downgrades. This way 3.0 3.1 3.2... can only be maintenance releases without any new features or relayout - will 2020's version be 4.0 then to accomodate for new features? 

 

If so, why don't we jump to 11 now and match our majors with Postgres majors? 

 

On пн, 9 ліп 2018, 23:03 Regina Obe <lr at pcorp.us <mailto:lr at pcorp.us> > wrote:

We've been quietly toying with this idea, but would like to put in stone.

Instead of having yet another minor of 2, let's go to 3.0.

Hey we went from 1.5 to 2, seems appropriate to go from 2.5 to 3.

All PostGIS developers and packagers I'd like your feedback too since it
will sway our decision.

My main reason for wanting to jump to 3.0 is so we can standardize on
dropping the minor version in our  lib file.

So that means 3.0 would have a lib file
postgis-3.whatever_extension_os_prefers.


No postgis-3.0  etc.  just postgis-3

And thenceforth all PostGIS from 3.0 on will no longer have the .minor
version and we will promise as a project to ensure we will not remove C-API
functions referenced in prior 3.whatever  SQL api and never do so during the
series of a major release.
Thus making pg_upgrade possible without having install an older version of
PostGIS or to do hacks symlink  lib files from older versions to newer or
having people have to ask us - is it okay to symlink?

+1 for 3.0 

Here are some other things on table for 3.0

https://trac.osgeo.org/postgis/wiki/PostGIS3  (breakout of postgis raster I
am totally against :) )

don't forget we've got a code sprint coming up this September to discuss
this and other topics.  Signup so we know how many people to expect.

https://trac.osgeo.org/postgis/wiki/PostGISCodeSprint2018


If you are only going to join remotely, it's okay to put your name on their
but with note (Remote)

Thanks,
Regina

_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/postgis-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20180709/e5f5ea94/attachment.html>