[xwiki-devs] Expand our support strategy to include a longer support period for the end of each cycle
21 May
2012
21 May
'12
9:22 p.m.
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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
21 May
21 May
9:54 p.m.
+1
Regards,
Sorin B.
On Mon, May 21, 2012 at 10:22 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> 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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
22 May
22 May
9:36 a.m.
+0, I'm not a big fan of the extra work but I understand the need.
On Mon, May 21, 2012 at 9:22 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> 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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
10 a.m.
+0
Thanks,
Marius
On Mon, May 21, 2012 at 10:22 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> 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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:15 a.m.
Hi,
strong +1. This is especially needed for larger deployments that cannot
migrate every 3 months.
Guillaume
On Tue, May 22, 2012 at 10:00 AM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
+0
Thanks,
Marius
On Mon, May 21, 2012 at 10:22 PM, Sergiu Dumitriu <sergiu(a)xwiki.com>
wrote:
--
Guillaume Lerouge
Sales - XWiki SAS
Skype: wikibc
Office: +33 1 45 42 40 90
Mobile: +33 6 10 79 76 70
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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
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
10:39 a.m.
New subject: [xwiki-devs] Expand our support strategy to include a longer support period for the end of each cycle
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.
WDYT?
Thanks
-Vincent
12:08 p.m.
On 05/22/2012 04:39 AM, Vincent Massol wrote:
On May 21, 2012, at 9:22 PM, Sergiu Dumitriu wrote:
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
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.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
23 May
23 May
10:16 a.m.
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 [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
_______________________________________________
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
10:54 a.m.
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.
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>wrote;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:
one
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 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.
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 we'll
have less people testing N.x and 6 months down the road N+1.x will be
less
tested.
think
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 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
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
27 May
27 May
6:29 a.m.
On 05/23/2012 05:46 AM, Eduard Moraru wrote:
Hi,
On Wed, May 23, 2012 at 11:54 AM, Guillaume Lerouge<guillaume(a)xwiki.com>wrote;wrote:
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.
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.
> 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
>> 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
> [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/
31 May
31 May
5:24 p.m.
Hi,
On Sun, May 27, 2012 at 6:29 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 05/23/2012 05:46 AM, Eduard Moraru wrote:
FTR, I strongly second Sergiu's position on this.
Guillaume
Hi,
On Wed, May 23, 2012 at 11:54 AM, Guillaume Lerouge<guillaume(a)xwiki.com>*
*wrote:
Hi,
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.
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.
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
>
>> 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
>>>
>> [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
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
27 May
27 May
6:02 a.m.
On 05/22/2012 04:39 AM, Vincent Massol wrote:
On May 21, 2012, at 9:22 PM, Sergiu Dumitriu wrote:
Users don't like being forced into doing things.
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.
Well, that's debatable. Most of the time, merging a commit into an older
branch usually takes me somewhere around 40 seconds:
git co -b stable-3.5.x --track origin/stable-3.5.x
git cp -x master
git push
git co master
git branch -d stable-3.5.x
That could take longer if there are merge conflicts, but that rarely
happens.
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)…
Again, almost all backport commits take less than a minute, how many
more features can one code in a minute?
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.
WDYT?
I'm not proposing that we do serious maintenance on this stable branch,
but just cherry-picking issues that are deemed important enough by the
developer that fixed it on the master branch, and which are easy enough
to backport. If clients want a new feature or improvement in that
branch, they can go through XWiki SAS or Kreablo AB or another company
that has committers on its payroll to try to get that backported, that
indeed is not the role of the open source community.
If you or other commiters don't want to "waste time" cherry-picking a
commit, then nobody forces them to. It's a best-effort maintenance
branch, similar to a LTS version like Ubuntu and Firefox have to satisfy
their enterprise users. Isn't XWiki an "enterprise" wiki as well?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
4491
days inactive
4501
days old
12 comments
8 participants
participants (8)
-
Caleb James DeLisle -
Eduard Moraru -
Guillaume Lerouge -
Marius Dumitru Florea -
Sergiu Dumitriu -
Sorin Burjan -
Thomas Mortagne -
Vincent Massol