Hi, I am one of the Darktable maintainers. Darktable 2.0 is going too be released soon. According to EPEL policies, I could not release such major release for EPEL/RHEL 7. Do you usually apply this rule strictly or sometimes you make an exception? New version of Darktable will rely on GTK3, but concerning the remaining libraries, there will not be a great change.
On 9 November 2015 at 13:30, Germano Massullo germano.massullo@gmail.com wrote:
Hi, I am one of the Darktable maintainers. Darktable 2.0 is going too be released soon. According to EPEL policies, I could not release such major release for EPEL/RHEL 7. Do you usually apply this rule strictly or sometimes you make an exception? New version of Darktable will rely on GTK3, but concerning the remaining libraries, there will not be a great change.
My usual decision tree on upgrades are: 1) Does upstream have a LTS edition? 2) Does the application upgrade itself cleanly?
If they have an LTS version, then I prefer that is what is in EPEL versus other tools. If they do not and they only fix the latest version then that usually means pushing to the newest semi long term version.
The next point is if the application upgrades itself cleanly or not. If an app can see the old configs and just go "ok I know that this works this way etc etc." then it can be easily upgraded in EPEL. If it doesn't then it comes down to how much pain will users and the developer have if it stays on an old version.
Sometimes the answer is that the product just doesn't belong in EPEL at all. Sometimes it means that you have to push to a newer version with notification to various lists that the pain train is coming and if you use the old version of the package expect some problems.
epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Il 09/11/2015 21:46, Stephen John Smoogen ha scritto:
On 9 November 2015 at 13:30, Germano Massullo germano.massullo@gmail.com wrote:
Hi, I am one of the Darktable maintainers. Darktable 2.0 is going too be released soon. According to EPEL policies, I could not release such major release for EPEL/RHEL 7. Do you usually apply this rule strictly or sometimes you make an exception? New version of Darktable will rely on GTK3, but concerning the remaining libraries, there will not be a great change.
My usual decision tree on upgrades are:
- Does upstream have a LTS edition?
- Does the application upgrade itself cleanly?
If they have an LTS version, then I prefer that is what is in EPEL versus other tools. If they do not and they only fix the latest version then that usually means pushing to the newest semi long term version.
The next point is if the application upgrades itself cleanly or not. If an app can see the old configs and just go "ok I know that this works this way etc etc." then it can be easily upgraded in EPEL. If it doesn't then it comes down to how much pain will users and the developer have if it stays on an old version.
Sometimes the answer is that the product just doesn't belong in EPEL at all. Sometimes it means that you have to push to a newer version with notification to various lists that the pain train is coming and if you use the old version of the package expect some problems.
1) No 2) Yes but once you open (with the 2.0 version) the XMP files attached to your photos, you cannot open them again with the older 1.6.x version, because the software updates those files to the newer format.
epel-devel@lists.fedoraproject.org