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