[geos-devel] NEWS comments

[Sebastiaan Couwenberg]

On 8/21/18 3:04 PM, Regina Obe wrote:
>> A few comments about NEWS:
>>
>>   I find the style of listing the alpha and rc separately confusing for
>>   those who go from 3.6.2 to 3.7.0 (should be almost everyone).  So
>>   instead of having them separate, I would start a "3.7.0 (not released
>>   yet)" section on the branch used fore 3.7 (which I guess is trunk
>>   after 3.6 branch was made) and then just start editing things in.
>>
> [Regina Obe] 
> I'm going to get rid of all of those at 3.7.0 (with just a note that the betas and rcs were released)
> The reason I put them separate is some of them aren't really newsworthy as they are fixes already included in 3.6.3 (so not new for 3.7.0)
> And will be dropped in the final release notes.  
> 
> And for people following the RCs/beta I wanted them to know exactly what they should be looking for in the changes as 3.7.0 changes are huge otherwise.
> But I guess for people coming in in a beta or rc it's kinda confusing.  I'm really not married to either approach as the new was more of an experimentation.
> 
> Show of hands (any one can vote)
> 
> Who prefers - just listing the 3.7.0 in one swoop and not mentioning the betas/rcs separately?
> 
> +0 for me for going back or forward.
> +1 for Greg for just listing 3.7.0 and betas and rcs together
> 
> If no more votes for or against I'll switch to just having as one listing.

Personally I like the separate NEWS items per release, even when one
does not follow all releases it makes it clear from which pre-release
the changes were available.

>>   The C++11 description is not entirely clear to me, and I think it
>>   should be extra loud up front.  It's a big deal as many systems have
>>   default compilers that are too old for C++11 (but this is a widespread
>>   issue with the combination of C++ and gcc).
> [Regina Obe] 
> Agreed will bring to the top of the news

C++11 is being adopted by other major components in the geospatial
ecosystem, GDAL most notably. This just means that people stuck with
compilers that don't support C++11 cannot build those new releases of
the projects in question. That's not much different than requiring
features of recent Qt5 releases for example, if you systems cannot
provide that, you're stuck with older releases.

As someone who values stability, I think this is a good thing.
Enterprise distributions with release cycles like Debian and
RedHat/CentOS shouldn't have to support building the latest and greatest
on their stable releases.

>>   Presumably there is no requirement to use C++11 anything to link
>>   against geos_c.   Perhaps that should be stated, even though it would
>>   be bizarre otherwise, given the amount of trouble that the C++/gcc
>>   siutation has caused.
> [Regina Obe] 
> I would think not.  Can someone else confirm this question?

Projects shouldn't use the GEOS C++ API, if they do, they get to deal
with the consequences (I'm looking at you OSSIM).

All projects, except ossim, in Debian that build on GEOS use the stable
C API which is not affected by the C++11 compiler requirements.

>From what I've seen of C++11, you probably want to adopt it for your C++
project anyhow, so if GEOS requiring it pushes that issue to the
forefront that's a good thing.

Kind Regards,

Bas