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

Bborie Park dustymugs at gmail.com
Mon Jul 9 13:42:32 PDT 2018


+1 for not aligning to PostgreSQL's change in versioning... *rabble*
*rabble* *rabble*

On Mon, Jul 9, 2018 at 1:28 PM Regina Obe <lr at pcorp.us> wrote:

> No No J
>
>
>
> 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> 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
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
> _______________________________________________
> postgis-devel mailing list
> 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/e543c3fa/attachment-0001.html>


More information about the postgis-devel mailing list