[PROJ] Release schedule between version 6.0.0 and 7.0.0

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[PROJ] Release schedule between version 6.0.0 and 7.0.0

Kristian Evers-2

All,

 

I have prepared a release schedule for the coming year. As always this is managed on GitHub [0]. For convenience, here’s an overview of the planned releases:

 

6.0.1                   May 1st 2019

6.0.2                   July 1st 2019

6.1.0                   September 1st 2019

6.1.1                   November 1st 2019

6.1.2                   January 1st 2020

6.1.3                   March 1st 2020

7.0.0                   March 1st 2020

 

Since the 6.0.0 release introduced massive amounts of new code I expect more bugs to be revealed than usually, hence the higher frequency of bug fix releases (every two months, unless a minor version release is scheduled). Note that 6.1.3 and 7.0.0 is planned for release on the same day. Since 7.0.0 will remove the proj_api.h header I expect that version 6 will be seen in the wild for quite some time after the 7.0.0 release and have therefore scheduled an additional bug fix release of the 6.1 branch. The maintenance status of the 6.1 branch should be re-evaluated once we are close to the release of 7.0.0. It may be necessary to issue a few more bug fix release based on the 6.1 branch until downstream projects has moved away from using the proj_api.h API.

 

The development strategy will be the same as we have used for the last couple of years: All changes are committed to the master branch and bug fixes will be cherry-picked into the relevant maintenance branch. As a consequence of this, development on version 7 cannot start before September 1st. This should not be a problem as the planned breaking changes for 7.0 at this time only consist of removing of proj_api.h – a task that is relatively easy to perform.

 

Please let me know if you have any comments or suggestions for changes.

 

/Kristian

 

[0] https://github.com/OSGeo/proj.4/milestones?direction=asc&sort=due_date&state=open


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Release schedule between version 6.0.0 and 7.0.0

Greg Troxel-2
[prematurely sent the previous]

Thanks - that all sounds good.

Certainly thinking about it later seems wise, but it's going to be
interesting to see how the transition to 6 in packaging systems goes.
While one can think about users making individual choices based on what
depending programs they want, and perhaps mulitple versions in different
prefixes or packaging approaches that basically use a prefix per package
(to avoid this issue), I think most people are going to be using what
their systems provide and thus either complaining that proj is old or
that foo is not available.

I wonder if it makes sense for proj to track the set of depending
projects that don't work with 6, with links to the tickets in those
projects' trackers.   That may be a step too far.

FWIW, postgis seems likely to have a 2.5.2 that works with proj 6 soon.
(2.5.1, the current release, does not.)

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Release schedule between version 6.0.0 and 7.0.0

Sebastiaan Couwenberg
On 2019-03-05 15:12, Greg Troxel wrote:
> I wonder if it makes sense for proj to track the set of depending
> projects that don't work with 6, with links to the tickets in those
> projects' trackers.   That may be a step too far.

I've considered this as well, and I think it's a good idea to do this
centrally instead of each distribution doing it on their own.

We could maintain a list on the GitHub wiki (e.g. PROJ6Compatibility),
with project details like:

  **<Project>**

  Compatible: Yes|No

  Version: x.y.z

  Issues:

   * [Upstream](https://example.com/issue/42)
   * [Debian](https://bugs.debian.org/123456)
   * [Fedora](https://bugzilla.redhat.com/show_bug.cgi?id=1234567)
   *
[NetBSD](https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=12345)

  Notes: Uses projects.h

Kind Regards,

Bas
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Release schedule between version 6.0.0 and 7.0.0

Kristian Evers-2
In reply to this post by Greg Troxel-2
The removal of the old APIs is certainly going to create some friction.
As Bas has stated many times there exist old packages that are unlikely
to be updated to use PROJ 6+. I am of the opinion that if a package is
that unmaintained it probably shouldn't be included in a package system.
That is of course easy for me to say, as I don't have to deal with all the
consequences of removing those package. It is important that we as a
community find a good solution to deal with this.

One solution to this transition phase we are in at the moment is for
packagers to maintain two PROJ packages: proj4 and proj. With proj4
being legacy PROJ (version <=5.2.0) and proj being an up to date version
(>=6.0.0). The proj4 package should probably only install shared libraries
and not command line utilities. I am aware that this approach will not be
suitable for everyone but it may be a good option for some.

It would be nice to have an overview of projects that depend on PROJ
and their proj.h adoption status. Bas made a list about a year ago of
the relevant packages in Debian. That is a good starting point, for anyone
who wants to maintain a list like this.

/Kristian


-----Oprindelig meddelelse-----
Fra: Greg Troxel <[hidden email]>
Sendt: 5. marts 2019 15:12
Til: Kristian Evers <[hidden email]>
Cc: [hidden email]
Emne: Re: [PROJ] Release schedule between version 6.0.0 and 7.0.0

[prematurely sent the previous]

Thanks - that all sounds good.

Certainly thinking about it later seems wise, but it's going to be
interesting to see how the transition to 6 in packaging systems goes.
While one can think about users making individual choices based on what
depending programs they want, and perhaps mulitple versions in different
prefixes or packaging approaches that basically use a prefix per package
(to avoid this issue), I think most people are going to be using what
their systems provide and thus either complaining that proj is old or
that foo is not available.

I wonder if it makes sense for proj to track the set of depending
projects that don't work with 6, with links to the tickets in those
projects' trackers.   That may be a step too far.

FWIW, postgis seems likely to have a 2.5.2 that works with proj 6 soon.
(2.5.1, the current release, does not.)

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Release schedule between version 6.0.0 and 7.0.0

Greg Troxel-2
In reply to this post by Sebastiaan Couwenberg
Bas Couwenberg <[hidden email]> writes:

> On 2019-03-05 15:12, Greg Troxel wrote:
>> I wonder if it makes sense for proj to track the set of depending
>> projects that don't work with 6, with links to the tickets in those
>> projects' trackers.   That may be a step too far.
>
> I've considered this as well, and I think it's a good idea to do this
> centrally instead of each distribution doing it on their own.
>
> We could maintain a list on the GitHub wiki (e.g. PROJ6Compatibility),
> with project details like:
>
>  **<Project>**
>
>  Compatible: Yes|No
>
>  Version: x.y.z
>
>  Issues:
>
>   * [Upstream](https://example.com/issue/42)
>   * [Debian](https://bugs.debian.org/123456)
>   * [Fedora](https://bugzilla.redhat.com/show_bug.cgi?id=1234567)
>   *
> [NetBSD](https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=12345)
>
>  Notes: Uses projects.h

Sounds good to me.   Completely agreed that having a shared list beats
many of us doing it separately.   I guess that's separate from the
project taking it on as their mission, but wiki pages are cheap.

I'm happy to put my notes in there as I come across them.


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Release schedule between version 6.0.0 and 7.0.0

Kristian Evers-2
I've set up a very simple GitHub wiki page for this purpose. I've just added
GDAL as an example for now. Feel free to add more to this.

https://github.com/OSGeo/proj.4/wiki/proj.h-adoption-status

/Kristian

-----Oprindelig meddelelse-----
Fra: PROJ <[hidden email]> På vegne af Greg Troxel
Sendt: 5. marts 2019 15:36
Til: Bas Couwenberg <[hidden email]>
Cc: [hidden email]
Emne: Re: [PROJ] Release schedule between version 6.0.0 and 7.0.0

Bas Couwenberg <[hidden email]> writes:

> On 2019-03-05 15:12, Greg Troxel wrote:
>> I wonder if it makes sense for proj to track the set of depending
>> projects that don't work with 6, with links to the tickets in those
>> projects' trackers.   That may be a step too far.
>
> I've considered this as well, and I think it's a good idea to do this
> centrally instead of each distribution doing it on their own.
>
> We could maintain a list on the GitHub wiki (e.g. PROJ6Compatibility),
> with project details like:
>
>  **<Project>**
>
>  Compatible: Yes|No
>
>  Version: x.y.z
>
>  Issues:
>
>   * [Upstream](https://example.com/issue/42)
>   * [Debian](https://bugs.debian.org/123456)
>   * [Fedora](https://bugzilla.redhat.com/show_bug.cgi?id=1234567)
>   *
> [NetBSD](https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=12345)
>
>  Notes: Uses projects.h

Sounds good to me.   Completely agreed that having a shared list beats
many of us doing it separately.   I guess that's separate from the
project taking it on as their mission, but wiki pages are cheap.

I'm happy to put my notes in there as I come across them.


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Release schedule between version 6.0.0 and 7.0.0

Sebastiaan Couwenberg
On 2019-03-05 15:48, Kristian Evers wrote:
> I've set up a very simple GitHub wiki page for this purpose. I've just
> added
> GDAL as an example for now. Feel free to add more to this.
>
> https://github.com/OSGeo/proj.4/wiki/proj.h-adoption-status

This is one step further than required for compatibility with PROJ 6
(and 5.x).

The biggest issue is the removal of projects.h, so dependent projects
need to use proj_api.h or proj.h. The former is sufficient to build
successfully with PROJ 6 (and 5.x).

Did you remove the other wiki pages on purpose? The wiki is very empty
now, any links to the old pages will be broken now.

Kind Regards,

Bas
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Release schedule between version 6.0.0 and 7.0.0

Kristian Evers-2
I am also interested in knowing if projects will be able to build against
PROJ 7 in a years' time, hence the three columns.

Feel free to change my template if you think there's a better way to keep
track of things. This was just a very quick and dirty job to get the ball rolling.

Yes, I purposely removed most of the other wiki pages. See my other email
for an explanation why.

/Kristian

-----Oprindelig meddelelse-----
Fra: PROJ <[hidden email]> På vegne af Bas Couwenberg
Sendt: 5. marts 2019 16:01
Til: [hidden email]
Emne: Re: [PROJ] Release schedule between version 6.0.0 and 7.0.0

On 2019-03-05 15:48, Kristian Evers wrote:
> I've set up a very simple GitHub wiki page for this purpose. I've just
> added
> GDAL as an example for now. Feel free to add more to this.
>
> https://github.com/OSGeo/proj.4/wiki/proj.h-adoption-status

This is one step further than required for compatibility with PROJ 6
(and 5.x).

The biggest issue is the removal of projects.h, so dependent projects
need to use proj_api.h or proj.h. The former is sufficient to build
successfully with PROJ 6 (and 5.x).

Did you remove the other wiki pages on purpose? The wiki is very empty
now, any links to the old pages will be broken now.

Kind Regards,

Bas
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Release schedule between version 6.0.0 and 7.0.0

Greg Troxel-2
In reply to this post by Kristian Evers-2
Kristian Evers <[hidden email]> writes:

> I've set up a very simple GitHub wiki page for this purpose. I've just added
> GDAL as an example for now. Feel free to add more to this.
>
> https://github.com/OSGeo/proj.4/wiki/proj.h-adoption-status

I added libspatialite.

I also added the notion of when things are fixed in actual releases vs
on the master branch, because packaging systems prefer releases and most
users do too.

I would say that depending packages should be update to build with proj
6, but they should continue to build with proj 5.2.0.   It makes things
much harder to have to do simultaneous updates.   I think given that
proj.h has been around for all of 5 and maybe even earlier, this is not
a problem.    I just wanted to point out that building with proj 6 and
not 5 is also a bug and will remain so until not updating to proj 6 is
lame, which I'd say is at least 6 months after the last significant
dependency has a release that works with it.
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Release schedule between version 6.0.0 and 7.0.0

Sebastiaan Couwenberg
On 3/6/19 3:41 PM, Greg Troxel wrote:
> Kristian Evers <[hidden email]> writes:
>
>> I've set up a very simple GitHub wiki page for this purpose. I've just added
>> GDAL as an example for now. Feel free to add more to this.
>>
>> https://github.com/OSGeo/proj.4/wiki/proj.h-adoption-status
>
> I added libspatialite.

I've added all packages in Debian that use PROJ (directly & indirectly).

Most have links to the upstream issue tracker.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj