Roman Lebedev wrote:

> Hi all.

Hello dev's, 

please find attached some thoughts about the planned deprecation.


 
> This mail is primarily targeted to all the owners of Nikon cameras.

bunch of them in the last decade, actually two.


> As you may have seen, an issue with white level for some
> nikon cameras (or so i thought) was discovered by me:
> https://www.mail-archive.com/darktable-dev@lists.darktable.org/msg01196.html
> 

great. really! 



> In the meantime i have adjusted white levels for all the cameras i
> could find samples for.

great. thx a lot. 


> But unfortunately, for some cameras i was unable to find samples.
> Below, you will find a list of all the cameras for which i need
> samples.
> 
> IMPORTANT: if you see your camera in that list, it is imperative for
> you to provide
> a sample set, or else your camera will not be supported in next
> darktable release!
> 
[...]

sigh.


meanwhile...
found D70 is on the way. 
hope the best for others.






kind regards
Wolfgang
# announced NIKON depreciation is a no-go

## first info

```
From: Roman Lebedev <lebedev...@gmail.com>
To: darktable-user <darktable-u...@lists.darktable.org>,  darktable <darktable-dev@lists.darktable.org>
Subject: [darktable-dev] PSA: ATTENTION NIKON OWNERS !!!
Date: Fri, 7 Oct 2016 16:00:48 +0300

[...]
or else your camera will not be supported in next
darktable release!
[...]
```

**shocking**


## why using open-source software

because it's sustainable. maybe not perfect. but good enough
1. First question for using a Digital Camera: is it in dcraw?
2. Second: always use RAW. Nothing else.

D70 raws from 2005? __NO Problem__. The camera has long gone.

## which software

* [dcraw](http://www.cybercom.net/~dcoffin/dcraw/) the reference
* [ufraw](http://ufraw.sourceforge.net/) always with me, even on 7year old netbook
* [darktable](http://darktable.org/) for work. and fun. and ...  (99% used)


# Confusion

## who is informed
* darktable-user
* darktable-dev

## who is not informed (maybe the other 98%)
* users of any distribution where some more-or-less actual version of darktable is provided

## what will happen if a dumb user updates a +0.0.1 version?
* backward incompatible changes will be introduced. (for darktable normal and accepted behaviour)
* loosing silently old pictures. ymmd.
* no easy rollback. depends on the time when you realize the breakage.

## and what happended to a git user
* #@!^^# in gui:
* failed to read camera white balance information from '2005...nef'  'working..' (stale)
* showing the skull icon after reentering lighttable

* only seen because started on command line:

```
[rawspeed] (20050507-15004070-NIKON_D70.nef) Camera not supported (explicit). Sorry.
[temperature] failed to read camera white balance information from `20050507-15004070-NIKON_D70.nef'!
[temperature] `NIKON CORPORATION NIKON D70' color matrix not found for image
[temperature] failed to read camera white balance information from `20050507-15004070-NIKON_D70.nef'!
[temperature] failed to read camera white balance information from `20050507-15004070-NIKON_D70.nef'!
allocation failed???

```

# Conclusion
i'm bored and disappointed. sorry.


# whats next

## taking a look at [semantic versioning](http://semver.org/)

whatever API means. (supported cameras, modules, xmp, database(es))
where database is more internal, could be regenerated out of xmp's.



```
Given a version number MAJOR.MINOR.PATCH, increment the:

    1. MAJOR version when you make incompatible API changes,
    2. MINOR version when you add functionality in a backwards-compatible manner, and
    3. PATCH version when you make backwards-compatible bug fixes.
```

point 7. for marking something deprecated ...
and then wait an amount of time i.e. one or two releases.
point 8. for introducing incompatible changes

my feeling: always all released versions shoud have been major? j/k


## giving a valuable feedback to the user
* version has to introduce a deprecation message when database of user shows findings
  (for ex: sql-ing for known cameras and give a big bummer on screen and log to provide raw files)

* keep non-optimal whitebalance stuff. better than to nuke. maybe mark previews.

Attachment: pgpUmd4xMc0v5.pgp
Description: OpenPGP digital signature

Reply via email to