Re: [Gimp-developer] how far from 2.10?

[Michael Natterer <mitch gimp org>]

On Thu, 2014-01-02 at 00:48 +0100, Ofnuts wrote:
> On 01/01/2014 03:10 PM, Jon Nordby wrote:
> > On 31 December 2013 23:26, Ofnuts <ofnuts laposte net> wrote:
> > > On 12/31/2013 06:36 PM, Marco Ciampa wrote:
> > > > Presumably how far are we to the new 2.10 gimp version?
> > > > How many blocking bugs are left and what are these?
> > > >
> > > > thanks and happy GNU year...
> > >
> > > Will it really be 2.10? Its internals are different, the file format is
> > > different (will 2.8 be able to load 16/32/FP files saved by the next
> > > version?), and it looks like many plugins won't work anymore and will need
> > > seroius rework...
> > Which plugins do you expect not to work anymore, and why?
>
> OK, maybe I'm pessimistic here, even if some of my python scripts had to 
> be reworked between 2.6 and 2.8, which have far less differences than 
> 2.8 and 2.10. Then in the current API there are still many values with 
> 0-255 ranges (gimp-drawable-{get|set}-pixel (),gimp-histogram) for 
> instance. So either there is absolutely no change in the API and the 
> script may produce sub-optimal results in images with high bit depth, or 
> there is some change and the script has to be reworked and may be made 
> bimodal or forked to support 2.8 and 2.10.

I did a really quick look at all non-deprecated PDB functions and
came up with a very short list (I'm sure some are missing, but it's
a harmless list that remains to be done):

limited range:

gimp-brightness-contrast
gimp-curves-explicit
gimp-curves-spline
gimp-drawable-set-pixel
gimp-drawable-get-pixel
gimp-levels

limited range unclear:

gimp-color-balance
gimp-posterize

missing:

gimp-buffer-get-format


> > 2.8 will not be able files from 2.10 using new features (naturally).
> > I believe files produced with 2.10 which _does not_ make use of
> > 2.10-only features can be opened in 2.8. Correct me if I am wrong.
> > 2.10 will be able to open all 2.8 files, of course.
>
> In the usual V.R.M numbering, the situation above is typically when you 
> change the version number (and maybe the file extension)... because my 
> point here is not the (completely understandable) incompatibilities, it 
> their understatement by calling the next version 2.10.

It's called 2.10 because it's binary and source compatible to 2.x.
We did not remove any functions, we only deprecated. That's the
only thing that counts, not how much has changed behind the
public API.

It's going to be called 2.10, you can stop arguing.

--Mitch