23 May
2012
23 May
'12
11:46 a.m.
Hi,
On Wed, May 23, 2012 at 11:54 AM, Guillaume Lerouge <guillaume(a)xwiki.com>wrote;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.
Thanks,
Eduard
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 <enygma2002(a)gmail.com
[N].0
we'll
on
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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> 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 is
people
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 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.
back.
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 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 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 > 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs