The following message concerns darktable major update 2.x (actually on EPEL7 = 1.6.x) My interpretation of EPEL packaging guidelines [1] is that the major update darktable 2.x should be pushed as a darktable2 package [2]. Moreover, once you read XML files (generated by darktable) of photos using darktable 2.x, you will not be any longer able to use them with darktable 1.6.x Kalev Lember said [3] about [1]: ====== I think this applies mostly to libraries in order to keep ABI/API stable in EPEL. I don't think the policy is meant to keep leaf desktop apps on old, unsupported versions forever. ====== Since Kalev is a reliable member of the community, I want to listen to his suggestion, but since I am not 100% sure, I would like to ask for a feedback from EPEL mailing list members.
Thank you for your time
[1]: https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Some_examples_of_w... [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1381507 [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1381507#c7
On Tue, 25 Oct 2016 16:02:04 +0200 Germano Massullo germano.massullo@gmail.com wrote:
The following message concerns darktable major update 2.x (actually on EPEL7 = 1.6.x) My interpretation of EPEL packaging guidelines [1] is that the major update darktable 2.x should be pushed as a darktable2 package [2].
In some cases yeah.
Moreover, once you read XML files (generated by darktable) of photos using darktable 2.x, you will not be any longer able to use them with darktable 1.6.x Kalev Lember said [3] about [1]: ====== I think this applies mostly to libraries in order to keep ABI/API stable in EPEL. I don't think the policy is meant to keep leaf desktop apps on old, unsupported versions forever. ====== Since Kalev is a reliable member of the community, I want to listen to his suggestion, but since I am not 100% sure, I would like to ask for a feedback from EPEL mailing list members.
Well, we need more information (or at least I do):
* Is 1.x still supported by upstream?
* is 1.x still supported by anyone else (rhel, other lts distros, people you could work with on backporting fixes).
* Are there any known 1.x security issues?
* Is the upgrade from 1.x to 2.x transparent for the user? ie, would they have to do any manual steps to move config? or is that all done by the application?
* Is the "user experence" different between 1.x and 2.x?
kevin
On Tue, Oct 25, 2016 at 11:07:28AM -0600, Kevin Fenzi wrote:
Well, we need more information (or at least I do):
- Is 1.x still supported by upstream?
I don't think so -- the last commit to the "darktable-1.6.x" branch is just over a year ago, Oct 21, 2015.
- Are there any known 1.x security issues?
I don't think there are any known outstanding ones — CVE-2015-3885 was fixed in 1.6.7.
- Is the upgrade from 1.x to 2.x transparent for the user? ie, would they have to do any manual steps to move config? or is that all done by the application?
It should be transparent, but it _is_ one way — if you make any edits in the new program, you can't go back.
- Is the "user experence" different between 1.x and 2.x?
Eh. Judgement call. I'd say it's fundamentally the same, but there are many differences in both functionality and look & feel.
Honestly, I think this is an example of an application which is not a great fit for EPEL. It'd be better if we would make a Flatpak which RHEL/CentOS users could transparently use.
Il 25/10/2016 19:07, Kevin Fenzi ha scritto:
Well, we need more information (or at least I do):
- Is 1.x still supported by upstream?
No
- is 1.x still supported by anyone else (rhel, other lts distros, people you could work with on backporting fixes).
I don't think so, and I have never seen a new 1.x release since darktable 2.x has been released
- Are there any known 1.x security issues?
No
- Is the upgrade from 1.x to 2.x transparent for the user? ie, would they have to do any manual steps to move config? or is that all done by the application?
No action is required by the user
- Is the "user experence" different between 1.x and 2.x?
It is almost the same, even if there are more features on 2.x
epel-devel@lists.fedoraproject.org
-
Germano Massullo -
Kevin Fenzi -
Matthew Miller