<div dir="ltr">Hi Berk,<div><br></div><div>I'd love to see long-term support for older versions of VTK.  It could be done without placing any burden on anyone but the people who need it, if a couple simple rules are followed:</div><div><br></div><div>1) When we move to VTK 7, an LTS branch should be created for VTK 6, and this branch should remain open for X years.  Merge requests etc. for this branch should be handled exactly as for the master branch.  We could have a list of developers willing to review patches for this branch on the wiki (I'd certainly be willing to do so).</div><div><br></div><div>2) There should be no expectation of binary releases from an LTS branch, that would just create extra work for Kitware and would probably end up slowing down the whole process.</div><div><br></div><div>3) There would have to be a section of the dashboard available for each LTS branch for nightly testing at least.  Merges into the LTS branch should be rare enough that @home testing would be unnecessary.  I realize that this might entail some gitlab customization.</div><div><br></div><div>I was not happy with how fast VTK 5 was dropped.  If there had been some way that I could have helped to support it, then I would have.</div><div><br></div><div>Here in academia, it's very common for projects to be put on hold for two or three years due to temporary lack of funding, or because a lab goes for a couple years without a grad student who has the necessary expertise.  So if a grad student gets stuck with a project that requires a version of VTK that won't work on a modern system, it becomes very difficult to even get started.</div><div><br></div><div> - David</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 10, 2015 at 9:31 AM, Berk Geveci <span dir="ltr"><<a href="mailto:berk.geveci@kitware.com" target="_blank">berk.geveci@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Maybe one way of addressing this issue would be to keep two versions maintained for a longer period? For example, we could commit to maintaining (minor bug fixes and limited testing only) VTK 6 for 3 years after we release VTK 7... That way customer that are stuck on old compiler can benefit from bug fixes and testing longer. If they want newer features, they would have to update. Given that we are likely to move to VTK 7 and then 8 pretty quickly, even longer than 3 years may be warranted.<div><br></div><div>I would argue for aiming for (mostly) C++ 11 by VTK 8, probably around late 2016.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-berk</div></font></span></div></blockquote></div></div></div></div>