Hi, On Sun, May 27, 2012 at 6:29 AM, Sergiu Dumitriu <[email protected]> wrote:
> On 05/23/2012 05:46 AM, Eduard Moraru wrote: > >> Hi, >> >> On Wed, May 23, 2012 at 11:54 AM, Guillaume Lerouge<[email protected]>* >> *wrote: >> >> Hi, >>> >>> this proposal is very similar to what Ubuntu does with LTS releases : >>> https://wiki.ubuntu.com/LTS . It's part of the work done by the >>> community, >>> not by the company (Canonical). >>> >>> The "test our latest features" use case is all nice and good, but it's >>> not >>> the actual use case of most XWiki users. Their use case is "we need >>> people >>> to work together using a stable, tested, reliable piece of software". >>> That's the use case that is strengthened by releases that are supported >>> for >>> a longer term. >>> >>> >> 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. >> >> > The end of each cycle is targeting stabilization. > The start of each cycle introduces the biggest changes. > Thus, the end of each cycles has the most "rock solid" versions that we > can offer. > The more serious the user is, the more he will want a "rock solid" version. > If we don't have any solid version to offer, there are other wiki engines > or CMSs that do take support seriously. > > I'm not proposing that each dev backports every fix. I'm proposing that if > we find some really important issues like "Customizing the PDF export via > CSS doesn't work anymore" or "Anonymous access to any document if the URL > is tweaked like this" or "Google bots can /delete/ any document regardless > of the wiki rights", they should be backported to the branch that most > enterprise users are going to use. It's not custom development for > customers, it's the minimal amount of respect that we owe to our users as > developers of a software that we dare to label as "Enterprise". > > We can't tell our users how often they should upgrade and to what version. > Saying that we don't want to have a LTS (where L stands for 6 months, not 3 > or 5 years) and that we want to force all our users to use the most recent > release doesn't characterize us as "true open source community", but as > "selfish jerks that don't care about their users". > > Linus doesn't handle stable branches maintenance because he has trusted > lieutenants that do that. Linus isn't the only community member that > develops the Linux kernel, every official stable branch is part of the open > source kernel. True, RedHat has other branches that they maintain in house > for their paying customers, but the fact that Chris Wright is on RedHat's > payroll doesn't mean that RedHat is actually doing the maintenance of the > stable kernel branches. And Greg, the main stable maintainer, is currently > being paid by the Linux Foundation. > > And Linux 2.4 should be the equivalent of XWiki 1.0.x, not 3.5.x. FTR, I strongly second Sergiu's position on this. Guillaume > 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<[email protected] >>> >>>> 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< >>>> [email protected]> 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 >>>>>> >>>>> > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > ______________________________**_________________ > devs mailing list > [email protected] > http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs> > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
