Currently our release performance says that we need 1 year for a release. So far we have more issues with the release process then with the development new feature process.
The whish to release 4.2.0 at end of this year is for our team super challenging. So I think we should take this challenge rather then try to boat 2 releases. If we get stuck for 4.2.0 for technical reasons or security reasons we can swap strategies. That's why we leave the prepared 4.1.5 trunk. So far my understanding of our current strategy. I think going for 4.1.5 is the conservative way. And another bugfix release has little support, right? Let's do this people. Go-Go for the 4.2.0 round :-D Am 28. Oktober 2017 22:18:20 MESZ schrieb Andrea Pescetti <pesce...@apache.org>: >Dave Fisher wrote: >> BTW - Damjan’s changes are javadoc related and absolutely needed on >modern Macs where getting JDK7 is not easy. We cannot be so >conservative that we are afraid of upgrades. > >Yes we can. And not only we can, but we should (a personal opinion of >course). > >It must be clear to everybody that trunk is the only place where >development is active. There it is important to try to support modern >systems as much as we can. But not on 4.1.x. > >4.1.x is frozen (and possibly even stopped). If we ever have to release > >something from 4.1.x again, we must strive to build it on the same VMs >used for 4.1.4 and the same configuration; this is our best guarantee >against regressions, and the proof is in the many 4.1.4-RCx. > >Regards, > Andrea. > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >For additional commands, e-mail: dev-h...@openoffice.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
