As I suspected a year ago, trying to maintain an app on top of an unstable core base is far worse than working off a stable branch and upgrading the app once it has stabilised. I’ve wasted too much time debugging core when I could have worked on new features and I never run the latest version of the server because it’s never stable. So there is really zero benefit to me.
So, I’m thinking about focusing on the stable branch of Gallery+ since the policy of the main projects is for official apps to commit to the development branch.
The benefits
Easier to review PRs for end-users
Faster merges
New features delivered quicker, depending on my availabilities and not on how broken master is
The drawbacks
Gallery might be broken when a new major version launches. It will really depend on how stable and backward compatible the core components will be or if someone else maintains that project
It might take longer for some features which require changes in core to be delivered
The process
PRs are done against the stable tree (Gallery+)
Most fixes from the stable branch upstream (security, design, etc.) are merged or taken into account
Test regularly on master and notify the core project if something unexpected is detected
Try to upgrade in the time between the server code freeze and release
Re-evaluate the situation from time to time
That’s of course, if I stay the maintainer of all those Gallery projects. If someone or a team wants to take over the official versions, they will be free to do whatever they want.
Probably, yes, especially if I have customers with large media collections.
The fact that ownCloud 9.1 will be able to execute tasks in the background should also help a lot.
So this mainly results in slower development of the normal Gallery app?
Maybe it makes sense to split the pure picture viewer from Gallery again then, because then that can be used independent of Gallery, and also with a potential future grid view? What do you think @oparoz?
Absolutely, given your current resources, you should extract the slideshow JS to a separate slideshow app. This could even become a component which can be used by any app (mail ;)) to offer a full size view of a picture.
The grid view would then fill the gap in terms of image management and be fully maintained by the core team. Gallery+ would offer a different experience and different features and will be free to have different requirements.
I think the speed is not really the issue since Gallery has 3 releases a year. The goal is to try and port Gallery+ features once for every release and as long as things are easily portable most will be ported with every server release. That’s on top of the ones created directly in Gallery.
The problem is that if too much has changed in the server, the old Gallery might not work any more. This sort of breakage will probably be easily detectable during the beta and rc phase of each NC release since the PHP side has good coverage, but if no resources are allocated to regularly check and fix Gallery, then NC might ship a broken app, like ownCloud did in the past, or an app without any additional features until the next release.
