While I like the ideas generally [1], some concerns and observations that I wish could be considered;
- active contributor crunch: we don’t have large number of active people working towards testing, fixing bugs and release, and reviewing/merging PRs on *master*; this affects the agility of any process or workflow we want to put in, or expect resolution in a certain window (3-5 days etc.); - diverse interests: our user-base may not necessarily want to upgrade to newer version of CloudStack even if they can proved to be quite stable; in-fact commercially some of us are paid to maintain stable branches and support users who are still on 4.2/4.3/4.4/4.5 etc; based on my experience, a typical enterprise users usually stick with a version (that works for them) for at least 6 months, while smb user or in-house consumers are quite agile who may upgrade as quickly as when new releases are made; - diverse branching/merging workflow usage and understanding: the bugfix workflow may not be acceptable (to go on master first), a lot of people have their own way of branching/merging in their organisations that affect how they do it in the the project - waiting time on new changes: since we don’t have large number of active testers and developers who can fix bugs rapidly, freezing master and doing the release may take a lot of time (unless if we can put a hard deadline or have some schedule to support that?), in which case new features and refactoring work will have to lay hanging (and some rebase/code-rework may be needed later when they are merged, when master is open) - release risk: after a release x.y.0 is made and since master can receive new features, refactoring work; the next x.y.1 can potentially add more regressions due to those new features and refactoring/re-architectural work - release maintenance and support demands: historically there has been an assumed or known stable release that is fairly tested in the wild and has built trust due to usage by users (through meetups, users ML, customer interactions etc), in the past those versions were 4.2.1 then 4.3.1/4.3.2, now based on my experience the last stable release is 4.5.1 [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack On 02-Jul-2015, at 5:16 pm, Remi Bergsma <r...@remi.nl<mailto:r...@remi.nl>> wrote: Hi all, We already agreed contributions should always go via a PR and require two LGTM’s before we merge. Let me propose the next step on how I think we should do release management for 4.6 and on. I talked to several people over the past weeks and wrote this wiki article: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack <https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack> If you like this way of working, I volunteer to be your RM :-) Like folks suggested earlier, it would be nice to work on this with multiple people. So, feel free to join. Maybe @dahn @bhaisaab and/or others are willing to teach me some of their tricks. Regards, Remi Regards, Rohit Yadav Software Architect, ShapeBlue [cid:9DD97B41-04C5-45F0-92A7-951F3E962F7A] M. +91 88 262 30892 | rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com> Blog: bhaisaab.org<http://bhaisaab.org> | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.