Re: [xwiki-devs] [VOTE] Change the way we do releases to include staging.

On Jun 9, 2012, at 6:28 AM, Sergiu Dumitriu wrote: I have one big problem with this strategy that I've already explained several past emails. The current way of doing staging with RC is very powerful because it's a real release and as such is advertised everywhere: on xwiki.org in download, in blog post, on twitter, on wikipedia, freshmeat, etc. Which means we have a lot of users who can download it and try it out. This will not happen with staging. It won't be advertised significantly (it cannot since it's not a real release) thus leading to a less good solution than what we have. Thus the only valid solution for me to reduce release cycles is to do 2 things at the same time: - work on the quality of our releases (i.e. increase our automated test suite and test coverage) - do short release cycle so that if a user finds a problem in say version 4.45 then we release 4.46 the week after or 2 days after if it's critical (this is basically what Jenkins is doing) Right now our cycle is 3 months for each release which means that if some dev cannot make the date for ex he has to wait 3 months for his stuff to be available to end users, which means devs are pushing stuff even if they are half baked (missing tests for example). Thus, with the current situation, I'd very much prefer to not do staging (in the sense of Nexus staging) and instead continue to use milestones and RCs. Now we can still do staging as a quick check for the RM before pushing to the main repo but it shouldn't last more than 1 day, as otherwise it adds up with the RC time and thus leads to even longer release cycles. <brainstorming> Moving forward: what we could do would be to reduce the whole cycle from 3 months to 3 weeks: * 1 week milestone 1 * 1 week milestone 2 * 1 week final (we need less time for stabilization over what we have now since there's less work done in m1/m2 than when they last 4 weeks each) If a developer doesn't have time to push his stuff in m1 or m2 then he'll have to wait only 1 week. Of course we should have Roadmap that last several releases so that we don't do roadmap preparation all the time and so that we can put large features in the roadmap that span more than 1 release. Actually the roadmap would list priority stuff we want to work on but will not say in what exact version we'll have it. The advantage of this is we'll get even more testing/feedback from community since we'll have real releases and users will get features/improvements/bugfixes pushed to them faster. The challenge is to keep good quality but I think we can do that and in any case there's only one way to know if it works: to try it ;) I think that without Sergiu's automated script for releases doing a release was too costly to do this. This means doing 3 releases in 3 weeks (ie. one per week). Is the automated script good enough to allow for this. Also we're going to have automated upgrades very soon now so it seems like upgrading versions is going to be less an issue for users (note that they don't have to upgrade at each version and they can skip releases). WDYT? Do you think the pace is sustainable for developers and that we won't spend too much time in "bureaucracies"? IMO this would help us automate our release process even further so that it becomes a nobrainer and will help us improve ourselves wrt quality/automated tests even further. There's one problem maybe with APIs. They need time to mature but with the young-api strategy that could be ok. <brainstorming> Thanks -Vincent