Re: [xwiki-devs] Expand our support strategy to include a longer support period for the end of each cycle

Hi, On Wed, May 23, 2012 at 11:54 AM, Guillaume Lerouge<guillaume(a)xwiki.com>wrote;wrote: But isn't this the purpose of the "stable" branch? As Vincent mentioned, I also think that's pretty much as stable as our small development team can provide. If we want a "rock solid" branch and there is a dev that can commit to that (again, as Vincent mentioned), sure. Otherwise, having each dev backport each fix for 2 older releases might be an overkill. So I`m +1 for Vincent`s proposal.

> This is especially true given that XWiki is still quite tough to upgrade as > soon as you've made some customizations to it. Thus I reiterate my strong > support for Sergiu's proposal to extend the support lifetime of > end-of-cycle releases. > > Thanks, > > Guillaume > > On Wed, May 23, 2012 at 10:16 AM, Eduard Moraru&lt;enygma2002(a)gmail.com >> wrote: > >> I also think we should encourage the community to always use and test out >> the latest version. >> >> Thanks, >> Eduard >> >> On Tue, May 22, 2012 at 1:08 PM, Caleb James DeLisle< >> calebdelisle(a)lavabit.com&gt; wrote: >> >>> >>> >>> On 05/22/2012 04:39 AM, Vincent Massol wrote: >>>> >>>> On May 21, 2012, at 9:22 PM, Sergiu Dumitriu wrote: >>>> >>>>> Hi devs, >>>>> >>>>> Given that each development cycle usually starts with bigger changes >>> and ends with a couple of stabilization releases, IMHO it makes sense > to >>> keep the last branch of a cycle maintained for a while longer. >>>>> >>>>> Our current strategy is to only support two branches at a time, the >> one >>> being developed, and the one before it. This means that as soon as > [N].0 >> is >>> released, [N-1].5.x is dropped. However, the [N-1].5.x branch is much >> more >>> stable and polished than the fresh new start of the cycle, so more > people >>> would be interested in using that stable version, especially in >> enterprise >>> situations. Thus, I propose to amend our support rule to keep the >>> end-of-cycle branch active for, let's say, 6 months. Still, this means >> only >>> that we backport major or critical issues, which would improve the >>> stability of that branch, without any new features. >>>> >>>> I don't like it because the point of the 2 branches only was twofold: >>>> >>>> 1) Force users to move to the newer version and thus help us test it. >>> Users get XWiki for free and it's good that they contribute something >> back. >>> Testing is contributing back. Your proposal basically means that you're >>> telling users: "Don't use the new N.0 release because it's not ultra >> stable >>> yet, instead, stay on N-1.5.x and wait 6 months. With this strategy > we'll >>> have less people testing N.x and 6 months down the road N+1.x will be >> less >>> tested. >>>> >>>> 2) It's more work. We already have a hard time maintaining N.x. For >>> example right now we have an important bug that was fixed in 4.0.1 and >>> we're not even releasing 4.0.1 when we should. Also we're fixing bugs > on >>> 4.1.x that we're not backporting to 4.0. >>>> >>>> Also note that this means less work done on the N.x and N+1.x and our >>> dev team is already very small (about 5-6 active committers)… >>>> >>>> I think I'd prefer a slightly different strategy: >>>> * As a team we keep the same rule as now, i.e. only 2 branches (dev >>> branch + stable) >>>> * If a given committer wants to maintain another branch himself a bit >>> more, he can do it but he should state it on a case by case basis so > that >>> others don't delete it and then it's up to him to backport stuff he > wants >>> to the branch and close it when it's no longer needed. >>> >>> I agree, I'm not opposed to old versions being supported but I don't >> think >>> it's the community's job. >>> I wouldn't expect Linus Torvolds to support 2.4.x, but RedHat can. >>> >>> Caleb >>> >>>> >>>> WDYT? >>>> >>>> Thanks >>>> -Vincent