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/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
