[gdal-dev] include paths and cmake

Mateusz Łoskot mateusz at loskot.net
Thu Nov 3 20:25:12 EDT 2011


On 3 November 2011 22:05, Even Rouault <even.rouault at mines-paris.org> wrote:
> Le jeudi 03 novembre 2011 22:33:38, Mateusz Łoskot a écrit :
>> On 3 November 2011 21:26, Kyle Shannon <KShannon at gcs-research.com> wrote:
>> > I believe that is on the 2.0 changes list, or something along those
>> > lines.  See:
>> >
>> > http://trac.osgeo.org/gdal/wiki/GDAL20Changes
>> >
>> > under House Keeping issues
>>
>> Great news!
>>
>> Frank, Even,
>> Can I set http://trac.osgeo.org/gdal/ticket/3435 with 2.0 milestone?
>
> There's was no 2.0 milestone created yet in Trac, so I've just created it.
> By the way, it's not clear (to me) if 2.0 will be the next version or if there
> will be a 1.10 before.

I was confused seeing "Related Tickets", I assumed it's query based on
milestone 2.0.

> I think that the ideas mentionned in GDAL20Changes are only brainstorming
> material for now that anyone can contribute to, but they should not be
> considered as officially approved until they will be seriously discussed. I can
> imagine that feedback, not only from developers, but also for the large crowd
> of users will be needed, so that each breaking change is pondered.

Sure. I guess some ideas may need to be supported with RFC.

> The main issue with 2.0 is that it should be the opportunity to do most
> breaking changes that can be anticipated for the next few years. But that also
> means that people that can contribute to it will need to have enough
> time/motivation/funding at the time that the works start, so that it ends up
> to be releasable in a reasonable amount of time (I'm just thinking to the
> libtiff 4.0 situation...).

OK

> There's also the risk of a fork of the community between users strongly
> attached to the old 1.X series (and potentially wishing improvements in the
> frame of this series) and users who will join the 2.X train. I'm thinking to
> the Python 2 vs Python 3 situation here.

Why it is a risk?
Freedom lies on both sides of the fence: on user's as well as on developer's.

> Looking at http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal makes you feel
> how many projects can be affected by the decisions that will be taken. And
> that's just the verbose crowd, not to mention the crowd of silent users that
> is likely much larger...

I dare to repeat myself: this is slogan.
It is cheaper to adapt client software to new version of library and
updated API,
than to maintain support library that doesn't follow new patterns,
techniques and technologies.
The alleged users/projects affection can be proved with arguments of the same
quality as my opinion.
Linux does not promise API/ABI stability between versions and it rules
the world.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org


More information about the gdal-dev mailing list