[xwiki-devs] Expand our support strategy to include a longer support period for the end of each cycle
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/
+1 Regards, Sorin B. On Mon, May 21, 2012 at 10:22 PM, Sergiu Dumitriu <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+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 <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+0 Thanks, Marius On Mon, May 21, 2012 at 10:22 PM, Sergiu Dumitriu <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 < [email protected]> wrote:
+0
Thanks, Marius
On Mon, May 21, 2012 at 10:22 PM, Sergiu Dumitriu <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Sales - XWiki SAS Skype: wikibc Office: +33 1 45 42 40 90 Mobile: +33 6 10 79 76 70
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
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 <[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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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. 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 <[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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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.
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/
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>
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.
Users don't like being forced into doing things.
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/
participants (8)
-
Caleb James DeLisle -
Eduard Moraru -
Guillaume Lerouge -
Marius Dumitru Florea -
Sergiu Dumitriu -
Sorin Burjan -
Thomas Mortagne -
Vincent Massol