> On 15 Sep 2016, at 13:23, Ecaterina Moraru (Valica) <[email protected]> wrote: > > On Thu, Sep 15, 2016 at 1:15 PM, Vincent Massol <[email protected]> wrote: > >> >>> On 15 Sep 2016, at 11:40, 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 + >> >> Could you be more specific? I don’t see any change for the RMs. >> >>> increases the >>> number of jobs and branches for versions + branches for partial >> features); >> >> Actually, as I’ve mentioned in my mail, it should decrease slightly the >> number of branches/jobs since we’ll have less bugfix releases for stable >> versions. Or keep it similar. But I don’t see an increase. >> >>> - 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 >> >> Yes that’s part of the rational I put: increase the testers and use more >> the community to test. >> >> Our scope has been increasing over the years (more features, more >> extensions). It’s important to use more and more the community to help us. >> >>> - the roadmap items planning might need more issues/bureaucracy. >> >> Possibly a bit. But the way I view this is that we’ll continue to do >> roadmaps every 3 months or so for the coming 3 releases and do the steering >> every month in case we want to change it slightly. >> >>> 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. >> >> It does. If you’re an existing user and you’re upgrading, say every 6 >> months, it won’t change anything ofc. >> >> But if you’re a new user, you’ll be able to use the latest released >> version. And report feedback, bugs, ideas, etc. You won’t start on a 3 >> months old release. >> >>> 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. >> >> You do look a bit resistant to change :) >> >> But that’s fine. It’s good to have someone playing the devil’s advocate. >> >> However, I haven’t seen any real cause for being worried so far. >> >> Honestly it's almost is a non event and doesn’t change much IMO. It just >> means removing the suffix “milestone” from our releases ;) >> >>> 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). >> >> Could you explain what you mean by butchering? Could you also explain what >> is not clear in: >> “[….]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.[…]" >> > > By butchering I meant having 8.4, 8.5, 8.6, 8.7, etc. and having to explain > the users that for the 8.x cycle the versioning strategy changed meanwhile > and 8.7 is equivalent to 7.4 final. But the thing is that I forgot that > 8.4+ were shorter releases, so I guess you are right: it doesn't change a > thing. By the end of the year we should have just 8.4 and 8.5.
Actually we’ve decided a while back to no longer have N.5 releases because we don’t have enough time at the end and we usually have to carry the remaining stabilization/polishing work in the next year. So the idea is to have 8.4 till around mid November (i.e. 1 month) and then to do bug fix releases of 8.4 every 2 weeks, i.e. 8.4.1, 8.4.2, etc. And then on Jan 2nd, start 9.0. Thanks -Vincent > Thanks for the explanations, > Caty > > >> >> So to remind you, the last stabilization release is already meant to be 1 >> month (we’ve been doing this for some time already, even doing it for the >> last 2 releases in the past when we had a N.5 release), so as I said, it >> doesn’t change anything. >> >> So in practice I could have omitted this part since it’s the same as >> saying we start only in 9.0 but I wanted to put us in the spirit of the new >> strategy ASAP. >> >> Thanks >> -Vincent >> >>> 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. >>>> >>>> Thanks >>>> -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
