Hi Cameleers, +1
I'm all for releasing sooner, one blocker that I see with this is that we can't really rely on the CI builds, they often break with out of memory or artifact errors, perhaps we should also take the opportunity to see if not using Jenkins Maven job type (for example Jenkins pipeline) would help that. I also wanted to experiment with hipster build tools (Buck, Blaze, Pants) and see if the build times can be drastically reduced, but there are only so many hours in the day :) zoran On Sat, Jul 8, 2017 at 9:58 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > I think it can benefit the community if we try to get a 2.20 release > out after the summer break, such as in early/mid September. > > The reason is that this release has some internal optimisations, > reduced object allocations, and faster startup that would benefit > Camel end users. Also end users can plugin the camel-headersmap module > to use a slightly faster map implementation for case-insensitive keys. > > There has also been work on improving the startup/shutdown sequence of > Camel when running in Spring so this happens better. > > On the same page I would also like to see us being able to do a bit > more frequent releases of Camel minor releases (eg 2.19, 2.20, 2.21 > etc) than only 2 times per year. If we can get the momentum up to > 2.5-3.5 times per year then that would be better. > > Any thoughts? > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 -- Zoran Regvart
