On Thu, Sep 15, 2016 at 11:47 AM, Ecaterina Moraru (Valica) <[email protected]> wrote: > Also the design for our Download page might not be optimal with this > change. Users will have to go more to the Other versions if they will be > 'recommended' a particular version (just like I said if they will adopt > some odd/even or divisibility by 5 rule, etc). > > Thanks, > Caty > > On Thu, Sep 15, 2016 at 12:40 PM, Ecaterina Moraru (Valica) < > [email protected]> wrote: > >> +0 I'm not thrilled since: >> - it will put pressure on the RMs (there are several steps additional done >> for final releases + the ci needs to be shiny perfect + increases the >> number of jobs and branches for versions + branches for partial features); >> - in theory all the releases should be tested fully (before we had a >> buffer to catch bugs between Ms + more time for the community to test the >> releases) and >> - the roadmap items planning might need more issues/bureaucracy. >>
>> Also users might be confused about the 'quality'/frequency of releases and >> they might adopt strategies like installing even/odd release version or >> just bugfix releases. So I'm not sure this will fix use case in terms of >> users feedback. We still have LTS for this. Like before users want to be safe will install LTS. >> >> It's just a feeling I have and I'm a bit worried since our community is >> small, but maybe I'm just resistant to change. I'm willing to try though. >> >> I would prefer 10 releases N.0 to N.9 (just for 'esthetic' reasons). Also >> I would have prefer to start this new version/release scheme for the 9.x >> cycle, instead of butchering the 8.4+ stabilization releases (for >> 'consistency' reasons). >> >> Thanks, >> Caty >> >> >> On Thu, Sep 15, 2016 at 12:18 PM, Vincent Massol <[email protected]> >> wrote: >> >>> Hi devs, >>> >>> Executive summary: >>> * Replace our 3 month release cycle by a 1 month release cycle. >>> >>> Needs and advantages: >>> * Be able to get our changes faster to our users. Importantly, bugfixes >>> are released faster to users. Note: it’s not because we release faster that >>> our users have to upgrade as fast. They can skip some versions if they >>> want/need. >>> * Be able to get more feedback more quickly from users. Right now, most >>> (if not all) of our users are testing only final versions. They’re not >>> testing milestones or RCs and thus we usually only know about problems >>> after the final has been released and we incorporate the change in the next >>> one (to be released 3 months later) or we have to do a bugfix release. >>> * Get closer to cloud needs. Nowadays, could offerings happen more and >>> more and operating a cloud means bringing improvements and fixes as fast as >>> possible. Some software in the cloud are even updated/patched several times >>> per day. We’re not there yet but we’re trying to get closer by reducing >>> from 3 months to 1 month >>> * This also means more marketing for the xwiki project since other site >>> relay the new whenever a final version is released >>> >>> Proposal Details: >>> * 1 month split in: 3 weeks to release a RC + 1 week to release the final >>> version. It’s very important to keep the RC as a meeting point and ensuring >>> all is going to be ready on time for the final release (jiras are closed or >>> moved to the next release, CI is passing, documentation and RN are ready, >>> etc). >>> * Split large features into smaller chunks. It doesn’t matter if some >>> code is released but unused for example (provided the build is passing). >>> For larger refactoring that absolutely cannot be split into 3 weeks chunks >>> (I’m not sure that really exists) then we can use branches (and create a CI >>> job to ensure integration). >>> * Less need for bugfix releases of stable versions. For LTS it’s still >>> required though. >>> * Note that this 1 month release strategy will not generate more releases >>> (and thus more work) over the year since we’re already releasing every 2-3 >>> weeks ATM (milestones, RCs, et) >>> * Version Naming: from N.0 to N.10 where N is the cycle name. The reason >>> for 11 releases and not 12 is to account for slippages + potential bugfix >>> release at the end of the cycle for stabilization + holidays. We might even >>> be able to do only 10 releases and not 11 but I’m suggesting we try with 11 >>> for now. >>> >>> When: >>> * I’m proposing to start this process with the 8.4 release (starting on >>> the 10th of October). Since that version is already supposed to be a >>> stabilization release (and thus a short 1 month release) it’s not going to >>> change anything. We should also do bugfix releases after 8.4 is releases: >>> 8.4.1, 8.4.2, etc till the end of the year >>> * Then starting 9.0 we really start doing 1 month releases. >>> >>> WDYT? >>> >>> Here’s my +1 to try this. +1 >>> >>> Thanks >>> -Vincent >>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
