Thanks a lot, Simon !
Some comments inline ...
[EMAIL PROTECTED] wrote:
Cons:
- Persistent storage became incompatible between revisions causing
support/upgrade problems.
We will offer some migration tools into 2.0 to migrate from 1.0/1.5 to 2.0.
- Possible corruption of persistent storage when JVM is killed.
Very true. This is due to the way data are written on disk. We have a
SynchOnWrite parameter which default to 14 seconds, but you can set it
to 0 or -1 (I don't remember) to tell the server to immediatly write
data on disk. This will slow down the writes, but this will guarantee
against data corruptions (almost). Anyways, we have to work a little bit
on this aspect, to offer the same protection of data against corruptions
when the server crash, or at least a way to restore a consistant database.
We have some kind of 'subversion like' interceptor which may help to
solve this problem. We currently use it to revert modifications in unit
tests, but our intention is to include this capability to recover from a
violent crash. This is expected in 2.0 too.
- Switching JDK versions between ADS 1.0 and 1.5 made upgrade of many
systems impossible (E.g. Upgrading JDK requires a new operating system
version on some IBM platforms).
We won't switch to JDK 1.7 before a long period of time, be sure of that !
- Bug fixes/patches are mainly applied to current trunk only which forces
us to take the latest version (or SNAPSHOT!) to get defects resolved - the
alternative being to maintain a branch of the source in-house which is
something we always try to avoid for obvious reasons.
This is not exactly true. We have two main 'branches' : 1.0 and 1.5.
The 1.0 branch is only used as a bug fix branch, and it moves (slowly)
to 1.0.3.
The 1.5 branch has always be clearly (???) exposed as the 'unstable'
branch, and is moving to a 'stable' 2.0 branch.
As the 1.5 branch is not considered as 'stable' (which means, in our
terms, that we can add new features), working in trunk is not totally
insane.
But it's not perfect... We have had passionate convos about this scheme,
and at the end, we decided that 1.5 should be seen as a intermediate
state from 1.0 and 2.0. This is the reason why we didn't delivered a
1.1, 1.2,... versions).
So in your case, yes, building from the trunk is the way to go, and this
is far from being perfect, I agree. Using SNAPSHOT is certainly not a
good idea...
At some point in the future, we will try to avoid such situations, and
to release intermediate versions (like 1.5.2, etc) to include some bug
fixes. This is what we did with 1.5.1, a bug-fix release. We didn't had
time to deliver a 1.5.2 for many reasons, one of them being that we have
some broken installers, and as we are supposed to be multi-platforms,
this is not an option to release under those conditions.
Sorry for this situation, this is obviously not a perfect one !
- Significant interface changes between revisions has led to regular rework
of our service container (our JBoss SAR implementation)
Very true. But this is also something we can't avoid at some point ...
3)
** I'd prefer no new features combined with a long period of stability and
maintenance **
The very same for us :)
But the project is also very young, and unperfect. We are working on that...
However, my top two improvements would be:
- Solid, proven, replication implementation (mitosis?)
At some point, I _think_ mitosis is somehow stable, but deserves more
tests. For that, we need real world users !
IMHO:
- ADS would benefit greatly from a sustained period of consolidation and
stability - no new JDKs, no more changes to public interfaces, no massive
refactoring exercises.
We are targeting this for 2.0. Consider that we have delivered 1.0 back
in october 2005, almost 2 years ago !!! (I can't believe time is flying
so fast ...) and 2.0 should be available in the next 6 months, that
would be 2 years between each majors. Not that bad, when you consider
that IBM delivers a new WebSphere every year ...
- Fixes to ADS should be routinely applied to the stable release as well as
the trunk.
We can't apply a bug fix to 1.5 and 1.0 at the same time, because the
1.0 code base is really different from 1.5; We try as hard as possible,
but we now consider 1.0 to be almost dead. The thing is that with the
JVM change occured when we started the 1.5 version, it's quite difficult
to maintain the same level of bug fixes in 1.0 and 1.5.
Now, 1.0 is by far less stable and slower than 1.5, and 2.0 should be
much more stable and faster than 1.5 too. 2.0 should be considered as
the next big thing, and should replace the 1.0 and 1.5 versions asap.
This is our target, in fact.
- I'm convinced that a well maintained, well document, long lived, stable
release is the only way ADS will gain widespread commercial implementation.
We totally agree. And this is what we are working on with 2.0. It should
be the 'production ready' ADS.
I will add something very important : we don't exist without users, and
without contributors. The frontier between users and contributor is very
thin : it's just a matter of a few mails, patches, proposals, and of
course dedication. All of our committers are people who at some point
were users, and became committers, because they proposed patches and bug
fixes...
Thanks a lot for your comments, Simon, we really appreciated them !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
