Re: Future maintainance releases
Kristian Evers <[email protected]> Wed, 30 Oct 2019 19:24:38 +0000
| Newsgroups | gmane.comp.gis.proj-4.devel |
|---|---|
| Message-ID | <[email protected]> |
> On 30 Oct 2019, at 12:12, Even Rouault <[email protected]> wrote: > >> No, not at all. My concern is, or was, that a 6.3 version would be rather >> short-lived with a release of 7.0 only a few months later. > > Depending on how much time it might take for 7.0 to be deployed to users using > binary distribution channels, we might have to maintain a 6.x for some time. That is certainly a possibility. But it is inevitable that the 6.x branch is going to go out of date no matter what. I don’t expect that we will be able to keep the EPSG database up to date for very long in 6.x for instance. > >> But if the >> changes you are proposing really are so disrupting I agree that it will be >> beneficial with a new minor-version release. I have one question though. >> Would it be a benefit to your work on vertical transforms if you were not >> restricted by the old API? The grid code is somewhat entangled as far as I >> remember and wouldn't be surprised if some of olde API functions is in the >> way of the smartest way to do things. If that is the case then I think we >> should just go straight to 7.0. If you can accomplish your work without >> working around the existing API a 6.3 release is fine with me. > > For now, I'm most dealing with metadata related work, nothing in the grid > handling itself. If the CDN related work happens to be done, yes it will be > internally disruptive, but looking quickly at proj_api.h, I'm not even sure > the old API would be a problem for that. The only thing that is grid related > is pj_apply_gridshift(), but I don't think that would be an issue, and looking > in Debian archive for > https://codesearch.debian.net/search?q=pj_apply_gridshift > I can only find mentions of it in PROJ itself or its embedded copies by other > projects, so basically no one in the open world is using it. > Right, in that case I think your proposal of introducing 6.3 in the next release cycle is the best thing to do. I will update the release schedule as follows: 6.3.0 January 1st 2020 7.0.0 + 6.3.1 March 1st 2020 From 7.0 and onwards I think I would like to move to issuing releases every three months as opposed to the bi-monthly cycle I’ve been keeping the last two years. It’s less of a burden on me preparing the releases and I expect the speed of development to slow down a bit now that the most significant chunks of database work is finalised. /Kristian > -- > Spatialys - Geospatial professional services > http://www.spatialys.com _______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj