24 Jul
2007
24 Jul
'07
11:17 p.m.
On 7/24/07, Vincent Massol <vincent(a)massol.net> wrote:
Hi Sergiu,
Sorry for taking so long to answer. The reason is that your email was
in my gmail spam folder till a few minutes ago...
See below.
On Jul 15, 2007, at 11:34 AM, Sergiu Dumitriu wrote:
OK for me. We'll make a vote when we thing we should switch to 2.0
Sergiu
--
http://purl.org/net/sergiu
Hi all,
The 1.1 deadline is approaching fast, and we still have a lot of
issues marked as bugs, and 2.0 is contouring very slowly. Thus, I
think we will need to decide whether we will have other 1.x releases
or start working on 2.0
Here are some factors I see:
- 2.0 will be mostly a rewrite from scratch, so all the existing bugs
will probably be fixed in 2.0
- Since there will be many differences between 2.0 and 1.x, we should
have a 1.x version without major known bugs, for those that don't want
to upgrade to 2.0
- We have a limited manpower, so working on both branches will be hard
- We will (probably) hire some new developers in the near future, so
we could split the people in two branches, if we must
- 2.0 will offer many new features that people are already asking for,
so we shouldn't delay it much longer.
I think we should make XWiki 1.2, but not more.
My vision is the following:
* Creating a 2.0 version from scratch is the best but we don't have
near enough manpower to work on 2 branches at the same time and we
cannot not maintain the 1.0 branch till the 2.0 is at the same exact
level as the 1.0 branch and till we have tools to automate migrating
users to the 2.0 branch.
My proposal (till we get more manpower, i.e. more active committers):
* We keep a single line of development, the XWiki 1.x one.
* We refactor aggressively XWiki 1.x to remove crutch and introduce
new APIs
* We allow ourselves to modifying any code not in the *.api package
and every time we make a potentially breaking change we document it
properly in the release notes
* We create new classes in the org.xwiki package and make the com.xpn
code use it and slowly remove old code.
* We introduce the "internal" keyword in package names to show that
any code in there isn't API-public. This means no user code should
have an import on a class that is in an internal package. See http://
jakarta.apache.org/cactus/participating/apis.html for more details
* We move com.xwiki.XWiki/XWikiDocument/etc in an internal package
and add the missing API methods to the *.api classes
* Once we have components in place that duplicate the feature in
*.api classes then we mark these methods as deprecated and we
announce that we only keep deprecated methods for 2 releases (for
example: 1.1 and 1.2). We put that deprecation strategy up on xwiki.org.
* We list all deprecated methods in the releases notes, stating when
they were deprecated so that we know when to remove them. We should
also create JIRA issue for removing deprecations.
I'm about to try implementing this by introducing Plexus and some
components. I have some preliminary code on my machine that works
very well but I need to write more logic so that I can swap some
existing code with it.
If we reach a stage where we decide we have to make a big break then
we can always decide at that time to make the jump to a 2.0 version
but at least the 1.x line will be closer to that 2.0 line.
WDYT?