Matt, Forgive me for not knowing but, why is keeping the minor release schedule important?
In my view spending time to fix things that are not working to give the community that we are improving stability is important. Many discussion on patch releases vs minor releases, boil down to give the impression of stability or innovation. From my personal usage, I would like a stable release version of ITKv4 installed on some systems for some scientists to use. I don't think that 4.2 is it yet. And unfortunately its not uncommon, for a release to contain a couple of bug that require a patch or two. In some situation stability is good. While when I want the latest features I frequently can pick a specific commit near master, that is suitable. Additionally, I don't think that both can really be done in the next 60 days, so I suggested just doing the patch. Brad On Jul 23, 2012, at 11:25 AM, Matt McCormick wrote: > Hi Brad, > > I think the performance issues and WrapITK issues are important enough > to justify a patch release. However, why substitute a minor release > that has other feature improvements? Keeping the minor release > schedule regular is important. > > My 2 cents, > Matt > > On Mon, Jul 23, 2012 at 1:55 PM, Bradley Lowekamp > <[email protected]> wrote: >> Hello, >> >> I have been considering what is being discussed to be done between now and >> September, when currently the 4.3 release is scheduled, along with the >> resources that I am aware that are available to contribute and add new >> features to ITK. I would like to propose that we change the scheduled >> release in september to only a patch release of 4.2. >> >> >> The fix for the performance regression that Kent and myself have worked on >> in quite significant and there is still work to be done there to try to >> whittle the maximum number of GetInput calls down further. Additionally, >> there are some WrapITK issues I have encountered when I instantiate more >> pixel types. And there is the important patch that has been contributed by a >> use to get WrapITK working with VS10. So I think there is some significant >> fixes that would justify a 4.2.1 patch release. >> >> >> This would not disrupt those working on the forward progress of the master >> branch either. Those patches intended to be merged into the release can >> through the normal gerrit process. The only difference would be that should >> be based on the release branch and not the master branch, and SHOULD NOT be >> rebased before they are merged into master. >> >> Thanks for sharing you thoughts on this issue. >> >> Brad >> >> >> ======================================================== >> >> Bradley Lowekamp >> >> Medical Science and Computing for >> >> Office of High Performance Computing and Communications >> >> National Library of Medicine >> >> [email protected] >> >> >> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Kitware offers ITK Training Courses, for more information visit: >> http://kitware.com/products/protraining.php >> >> Please keep messages on-topic and check the ITK FAQ at: >> http://www.itk.org/Wiki/ITK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://www.itk.org/mailman/listinfo/insight-developers >> ======================================================== Bradley Lowekamp Medical Science and Computing for Office of High Performance Computing and Communications National Library of Medicine [email protected]
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://kitware.com/products/protraining.php Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-developers
