On Thu 11 Apr 2013 03:10:58 AM EDT, Christian Hammond wrote:
> Hi Stephen,
>
> I don't know, and it hasn't been tested.
>
That's fine, I understand. I mostly needed to know if I needed to add a
strict dep on the 1.4 series. Looks like it would be wise to do so until
we have more information.
> So, this is a discussion we need to have. We will not be supporting
> Django 1.5 for Review Board 1.7, and we may need to stop updating to
> newer Django releases. (Just what you wanted to hear, right?)
>
> The Django guys keep making decisions to deprecate things and change
> things that severely impact us and make it really hard to migrate to.
> Things like their recent changes to how user profiles work (they're
> getting rid of them and all API around them). It's fixable, but we end
> up jumping through hoops just to change things for the sake of
> changing things.
>
> Along with that, they're deprecating Python releases faster than I'd like.
>
> It's possible that we won't support Django 1.5 for Review Board 1.8.
> We might, but that's not currently where our efforts are focused.
>
> So, I don't know what to do about that, because obviously that's going
> to be a problem for you guys, but I don't have a good solution.
>
> All that said, I'd take patches to start porting over to Django 1.5.
> We can't focus on it right now though. For now, yes, everything needs
> to be tied to Django 1.4.
>
This is going to provide an interesting support problem. The Django
upstream only supports two releases at one time (as I understand it). As
soon as they release 1.6, there will be no more updates for Django 1.4
(including security updates).
That's a really serious problem for supportability. What are you
planning to do when someone discovers a security vulnerability in Django
1.4.5 a year from now? Upstream won't be releasing patches.
I maintain ReviewBoard as a hobby, as does the Django maintainer in
Fedora/EPEL. Neither of us is paid to work on it and we don't have
anywhere near the capacity to maintain a fork of Django 1.4 once it
becomes unsupported. Our current plan in Fedora/EPEL is to always carry
whichever two versions of Django are supported by upstream.
So if ReviewBoard doesn't grow support for newer releases, we'll be
forced to drop it from Fedora/EPEL (which I really don't want).
One approach that might be feasible would be to put ReviewBoard on an
alternating-Django release schedule. Instead of going through the
upgrade pain at every Django release, make it so that ReviewBoard
targets each new even-numbered Django release.
That would reduce the backwards-incompatible change problem by about
half at least.
The other option would be to petition Django upstream to start producing
LTS releases that would see a longer lifecycle. Or alternately, impress
upon the Django upstream that backwards-incompatible changes will
prevent people from actually using Django to produce useful products.