[pgrouting-dev] PostGIS 2.1, Postgresql 9.3 and pgRouting - We need a plan!

Daniel, et al,

PostGIS 2.1 is hitting feature freeze to sync up with
PostgreSQL 9.3 which is going to Beta

And we need to be able to support PostGIS being able to package a pgRouting on Windows with PostGIS 2.1. I already have pgrouting build in the postgis build bot, so the focus should be on the code and sql fixes as I outline below.

So I think we need a plan for this, and some people effort would be good also.

It seems to me that we need someone to:

Setup an environment with pg 9.3 beta, postgis 2.1 trunk and take our pgrouting master and make changes required to make it work in that environment and package up a release.

This should not include any new features.
It should include ST_ fixes that we have a pull request for
It should include some of the bug fixes that we have pull requests for
It must include any additional compatibility changes.
It must include some basic testing (we can pull the tests from my 2.0 branch to make things simple)

This would be called version 1.06

This needs to happen after we move the branches around, which I hope to get to on Sunday.

Anyone available to manage this release and tackle the items above?
Anyone able to fund this at any level?

Thoughts?

-Steve

On Sat, May 4, 2013 at 10:25 AM, Stephen Woodbridge <woodbri@swoodbridge.com

wrote:

Daniel, et al,

PostGIS 2.1 is hitting feature freeze to sync up with
PostgreSQL 9.3 which is going to Beta

And we need to be able to support PostGIS being able to package a
pgRouting on Windows with PostGIS 2.1. I already have pgrouting build in
the postgis build bot, so the focus should be on the code and sql fixes as
I outline below.

So I think we need a plan for this, and some people effort would be good
also.

It seems to me that we need someone to:

Setup an environment with pg 9.3 beta, postgis 2.1 trunk and take our
pgrouting master and make changes required to make it work in that
environment and package up a release.

This should not include any new features.
It should include ST_ fixes that we have a pull request for
It should include some of the bug fixes that we have pull requests for
It must include any additional compatibility changes.
It must include some basic testing (we can pull the tests from my 2.0
branch to make things simple)

This would be called version 1.06

This needs to happen after we move the branches around, which I hope to
get to on Sunday.

Anyone available to manage this release and tackle the items above?
Anyone able to fund this at any level?

Thoughts?

-Steve
______________________________**_________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev&lt;http://lists.osgeo.org/mailman/listinfo/pgrouting-dev&gt;

Hi Steve,

"PostGIS 2.1, Postgresql 9.3 and pgRouting" ... this is particularly for
Windows builds, isn't it?
Unfortunately on Windows I have close to zero experience.

I don't know how much time would be still available, but wouldn't it be
possible (and less work) to use the new 2.0 version instead of trying
another 1.06 release?
Pulling changes from here and there might cause new issues and then we had
to work on two releases at the same time. Otherwise we could just focus on
one.

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

On 5/3/2013 10:00 PM, Daniel Kastl wrote:

On Sat, May 4, 2013 at 10:25 AM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>> wrote:

    Daniel, et al,

    PostGIS 2.1 is hitting feature freeze to sync up with
    PostgreSQL 9.3 which is going to Beta

    And we need to be able to support PostGIS being able to package a
    pgRouting on Windows with PostGIS 2.1. I already have pgrouting
    build in the postgis build bot, so the focus should be on the code
    and sql fixes as I outline below.

    So I think we need a plan for this, and some people effort would be
    good also.

    It seems to me that we need someone to:

    Setup an environment with pg 9.3 beta, postgis 2.1 trunk and take
    our pgrouting master and make changes required to make it work in
    that environment and package up a release.

    This should not include any new features.
    It should include ST_ fixes that we have a pull request for
    It should include some of the bug fixes that we have pull requests for
    It must include any additional compatibility changes.
    It must include some basic testing (we can pull the tests from my
    2.0 branch to make things simple)

    This would be called version 1.06

    This needs to happen after we move the branches around, which I hope
    to get to on Sunday.

    Anyone available to manage this release and tackle the items above?
    Anyone able to fund this at any level?

    Thoughts?

    -Steve
    _________________________________________________
    pgrouting-dev mailing list
    pgrouting-dev@lists.osgeo.org <mailto:pgrouting-dev@lists.osgeo.org>
    http://lists.osgeo.org/__mailman/listinfo/pgrouting-dev
    <http://lists.osgeo.org/mailman/listinfo/pgrouting-dev&gt;

Hi Steve,

"PostGIS 2.1, Postgresql 9.3 and pgRouting" ... this is particularly for
Windows builds, isn't it?
Unfortunately on Windows I have close to zero experience.

I don't know how much time would be still available, but wouldn't it be
possible (and less work) to use the new 2.0 version instead of trying
another 1.06 release?
Pulling changes from here and there might cause new issues and then we
had to work on two releases at the same time. Otherwise we could just
focus on one.

Daniel,

I think the problem is much easier than that. We need to do be able to support this release on Linux also. For that matter we need to support 9.1, 9.2 and postGIS 2.0 which we don't today resulting in every user asking the list how to get it to work.

So, we build and test on linux.
Regina can pull our source into the build bot.
I can build on Windows here (if I have to).
and we just plan to cut 1.06 release on Linux that fixes some bugs and compatibility issues.

If we plan it like this then its more about the bugs, and compatibility and yes at some point it gets tested on windows and if there are windows specific issues, Regina and I can sort them out and check changes back into the branch.

CC: Regina since she needs to interact with our efforts.

-Steve

For the record I know your 1.07 branch builds (and for the tests I've done
works fine with PostGIS 9.2 (both 32-bit and 64-bit) and 2.1 except for the
bug I mentioned to Steve already with a driving distance call which is a
pgRouting bug not a windows one), but haven't tested against 9.3.
I haven't had a chance to test the pgrouting 2.0 branch yet.

I do have winnie pulling both 2.0 and 1.0 pgrouting branches, but have to
strap up to compile and test against both 9.2 and 9.3. Hoping to do that
this weekend or next week.

Thanks,
Regina

-----Original Message-----
From: Stephen Woodbridge [mailto:woodbri@swoodbridge.com]
Sent: Friday, May 03, 2013 10:17 PM
To: pgrouting-dev@lists.osgeo.org; Paragon Corporation
Subject: Re: [pgrouting-dev] PostGIS 2.1, Postgresql 9.3 and pgRouting - We
need a plan!

On 5/3/2013 10:00 PM, Daniel Kastl wrote:

On Sat, May 4, 2013 at 10:25 AM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>> wrote:

    Daniel, et al,

    PostGIS 2.1 is hitting feature freeze to sync up with
    PostgreSQL 9.3 which is going to Beta

    And we need to be able to support PostGIS being able to package a
    pgRouting on Windows with PostGIS 2.1. I already have pgrouting
    build in the postgis build bot, so the focus should be on the code
    and sql fixes as I outline below.

    So I think we need a plan for this, and some people effort would be
    good also.

    It seems to me that we need someone to:

    Setup an environment with pg 9.3 beta, postgis 2.1 trunk and take
    our pgrouting master and make changes required to make it work in
    that environment and package up a release.

    This should not include any new features.
    It should include ST_ fixes that we have a pull request for
    It should include some of the bug fixes that we have pull requests for
    It must include any additional compatibility changes.
    It must include some basic testing (we can pull the tests from my
    2.0 branch to make things simple)

    This would be called version 1.06

    This needs to happen after we move the branches around, which I hope
    to get to on Sunday.

    Anyone available to manage this release and tackle the items above?
    Anyone able to fund this at any level?

    Thoughts?

    -Steve
    _________________________________________________
    pgrouting-dev mailing list
    pgrouting-dev@lists.osgeo.org <mailto:pgrouting-dev@lists.osgeo.org>
    http://lists.osgeo.org/__mailman/listinfo/pgrouting-dev
    <http://lists.osgeo.org/mailman/listinfo/pgrouting-dev&gt;

Hi Steve,

"PostGIS 2.1, Postgresql 9.3 and pgRouting" ... this is particularly
for Windows builds, isn't it?
Unfortunately on Windows I have close to zero experience.

I don't know how much time would be still available, but wouldn't it
be possible (and less work) to use the new 2.0 version instead of
trying another 1.06 release?
Pulling changes from here and there might cause new issues and then we
had to work on two releases at the same time. Otherwise we could just
focus on one.

Daniel,

I think the problem is much easier than that. We need to do be able to
support this release on Linux also. For that matter we need to support 9.1,
9.2 and postGIS 2.0 which we don't today resulting in every user asking the
list how to get it to work.

So, we build and test on linux.
Regina can pull our source into the build bot.
I can build on Windows here (if I have to).
and we just plan to cut 1.06 release on Linux that fixes some bugs and
compatibility issues.

If we plan it like this then its more about the bugs, and compatibility and
yes at some point it gets tested on windows and if there are windows
specific issues, Regina and I can sort them out and check changes back into
the branch.

CC: Regina since she needs to interact with our efforts.

-Steve