Le dimanche 11 novembre 2012 20:00:37, Ben Discoe a écrit :
> +1 to everything Ragi said.
>
> Version "numbering" like "1.10" is an affront to common sense and the basic
> concept of the decimal system, not to mention every OS's filename sorting.
> If 1.10 comes after 1.9, then it would be imperat
On 11 November 2012 19:00, Ben Discoe wrote:
> +1 to everything Ragi said.
>
> Version "numbering" like "1.10" is an affront to common sense and the basic
> concept of the decimal system, not to mention every OS's filename sorting.
> If 1.10 comes after 1.9, then it would be imperative to replace
-Ben
> -Original Message-
> From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-
> boun...@lists.osgeo.org] On Behalf Of rburhum
> Sent: Friday, November 09, 2012 7:59 AM
> To: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] Which version number for the next GDAL release
Perhaps calling it 2.0 is not a bad thing and it sounds of less of a hassle.
Breaking the ABI (by rushing major API changes) just so that the semantics
of what "2.0" means, seems inappropriate. If/when the unification starts, we
could bump it to 3.0, 4.0 or any other number. There are quite a few o
On 8 November 2012 21:49, Even Rouault wrote:
>
> I'm also wondering if we shouldn't introduce a macro to compute the version
> number, like
> #define GDAL_COMPUTE_VERSION(maj,min,rev, build)
> (maj*100+min*1+rev*100+build)
>
> so that tests can be written more naturally (the new version n
Le jeudi 08 novembre 2012 23:09:16, Frank Warmerdam a écrit :
> On 12-11-08 01:49 PM, Even Rouault wrote:
> >> I appologise to Howard or others who have been tuning configuration
> >> logic for a 2.0 release.
> >
> > It depends on how they have tuned...
> >
> > We have a small technical detail to
On 12-11-08 01:49 PM, Even Rouault wrote:
I appologise to Howard or others who have been tuning configuration logic
for a 2.0 release.
It depends on how they have tuned...
We have a small technical detail to solve with 1.10 because of
# define GDAL_VERSION_NUM
(GDAL_VERSION_MAJOR*1000+GDAL_
> I appologise to Howard or others who have been tuning configuration logic
> for a 2.0 release.
It depends on how they have tuned...
We have a small technical detail to solve with 1.10 because of
# define GDAL_VERSION_NUM
(GDAL_VERSION_MAJOR*1000+GDAL_VERSION_MINOR*100+GDAL_VERSION_REV*1
Folks,
While I hate ".10" versions it is clear that I/we aren't yet doing the
2.0 "grand unification" and so I don't feel a 2.0 version is appropriate
given the nature of current work.
I had originally though to just hold off on the release for longer to
allow for 2.0 work to be done, but I hav
Concerning the stub implementations, there are a lot of examples where the
current api contains arguments, which are just stubs for future...
--
Lähetetty Nokia N9 -puhelimestani
Even Rouault kirjoitti 7.11.2012 21:45:
>
> RFC 39 (the layer algebra) does break the C ABI, I believe.
No, i
Le jeudi 08 novembre 2012 14:24:12, Etienne Tourigny a écrit :
> Hi,
>
> I think it should be 1.10, I don't see any major difference with 1.9
> and no major api changes. I see it more like an incremental release
> than a major milestone.
Yes, exactly
>
> I recall some time ago a discussion abou
Hi,
I think it should be 1.10, I don't see any major difference with 1.9
and no major api changes. I see it more like an incremental release
than a major milestone.
I recall some time ago a discussion about the unification of ogr and
gdal, and that goal still seems pretty far (unless I missed
som
07.11.2012 23:17, Even Rouault пишет:
Hi,
I'm wondering if we shouldn't release GDAL trunk as GDAL 1.10 instead of GDAL
2.0.
I think that 2.0 is a good motivation to make more global changes.
Though we have an example of version shift in Linux kernel from 2.x to 3.x.
As far as I know, there h
>
> RFC 39 (the layer algebra) does break the C ABI, I believe.
No, it does not break anything. It *adds* new entry points, like all previous
releases have done. Which is OK as far as backward compatibility is concerned.
> How about making the changes to the API but not implement them...?
Tha
On 11/07/2012 09:17 PM, Even Rouault wrote:
Hi,
I'm wondering if we shouldn't release GDAL trunk as GDAL 1.10 instead of GDAL
2.0.
As far as I know, there haven't been yet any change in GDAL trunk that
qualifies as a major re-architecturing, or that breaks the C API & ABI of the
GDAL 1.X series
On Nov 7, 2012, at 1:17 PM, Even Rouault wrote:
> Hi,
>
> I'm wondering if we shouldn't release GDAL trunk as GDAL 1.10 instead of GDAL
> 2.0.
>
> As far as I know, there haven't been yet any change in GDAL trunk that
> qualifies as a major re-architecturing, or that breaks the C API & ABI o
Hi,
I'm wondering if we shouldn't release GDAL trunk as GDAL 1.10 instead of GDAL
2.0.
As far as I know, there haven't been yet any change in GDAL trunk that
qualifies as a major re-architecturing, or that breaks the C API & ABI of the
GDAL 1.X series. I'm not sure if or when someone will want
17 matches
Mail list logo
