On Thu, Feb 24, 2011 at 10:36 AM, Hanno Schlichting <ha...@hannosch.eu> wrote: > On Thu, Feb 24, 2011 at 3:26 AM, Elizabeth Leddy <ele...@umich.edu> wrote: >> Feel free to respond over email or just edit the >> document: http://dev.plone.org/plone/wiki/PlipProcess > > Great work!
Agreed! This has the potential to greatly improve our process and provide the larger community of developers and users with a more certainty about how and when things are happening in the shadowy world of framework decisions and release management. >> In general, I'd like to give the fixed release schedule a 6 month test >> drive. If it sucks we can go back to status quo or move forward with the >> latest and greatest. > > I cannot remember any Plone releases that only took 6 months - even > when we tried hard. I'd usually expect a 50% overrun from any stated > timeline, so while aiming for 6 months we can manage to do a release > after 9 months. We'd have to aim for a 3-4 months cycle to actually be > able to do two releases in a year. > > And I wouldn't really want to do more than two releases per year, or > we risk getting too fragmented, diverging code bases and very short > support lifecycles for each release (only the last 4.x release gets > bugfixes at any given time according to our current policy). > > I think we could aim for a spring and an autumn release, expecting > most people to be busy in summer vacations and around x-mas/new year. I agree strongly with this. A 3 month cycle seems really ambitious. While ambition may be a good thing here, we need to think about the consequences of such a short cycle. This could drastically shorten the support lifetime of any given release. Is that something we really want to do? It could also put a huge burden on release managers with respect to minor/bugfix releases (especially if we decide to support more of these 3-month releases at a time). We might be better off with the more realistic and practical goal of trying to achieve a true 6-month cycle. It seems likely that this process will require a also larger "team" for any given release (particularly given the historic attrition rate of team members over the course the review process), along with a reasonable mechanism for members to opt-out of a particular cycle if needed. Alec _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team