This is excellent feedback Simon. You make some very good points which our version scheme was designed to support but we have not religiously adhered to it. This is a good time to point out why we must follow it and what it is:
Stable Bug Fix Branches
All new major releases start up a bug fix branch with a '0' for the minor number: 1.0, 2.0, 3.0 .... Fixes in these branches are ONLY to fix bugs. No one should f**k around with API's or generics or what ever itch they get in their arse that day. I'm sick and tired of people taking this lightly and causing a mess because they cannot control themselves.
Experimental Release Branches
Experimental release branches use a '5' for the minor number: 1.5, 2.5, 3.5 .... Changes in these branches are not guaranteed to abide by any contract. The developers are free to do what they like and release from this branch as they see fit within the legal framework of the ASF. So massive changes are allowed here. Any kind of tinkering is allowed here as long as we follow some commitequette.
So this model will make people like Simon of which we have many happy. However there are other factors that make this hard to do. Basically this is a balancing act between time and getting new features out in the server to our users.
What happened with 1.0 and 1.5?
1.0 was our first release and most of us hate it. I personally don't want to work on it ever again because of the bad design decisions (I made most of the time). It's slower, less stable, less maintainable, and far too brittle for my patience. I feel my time and the time of others are better spent fixing these limitations in 1.5. However we did release a few bug fix candidates. Granted not as many as we wanted to but then again we're all volunteers.
So what happened? We recommend that new people start using 1.5 instead because even though it is experimental, it is much more stable and robust than 1.0. We kind of blurred our rules a little bit.
My Views, and Vision on Server Development
Servers are special. They get started and have to stay up for a long a**ed time. So don't pick at them or be too liberal with changes to them. Once you make a GA release just apply bug fixes to it and test the heck out of it. Stability is critical.
For example Studio is a client side application. It can be started and stopped when needed. So things like leaks and other problems do not compound themselves into massive failures. Months or years of uptime can do this. Plus there's threading and other concurrency issues along with performance aspects. This is why the Studio release model does not need to follow the same model as ApacheDS.
Linux is a great example. Linux had a great model for this before they got all retarded with having to compete on the Desktop. They used to have a stable release branch with even minor numbers. Remember these 2.2 , 2.4, 4.2 etc ... The experimental branches were using odd minor numbers like 2.3, 2.5, 4.3 whatever. This is because a server needs to be broken in and have bugs and issues flushed out of new potentially destabilizing features. The Linux Kernel Developers knew this. But unfortunately since desktop hardware changes very fast in comparison to server hardware they changed the model to release newer versions as stable versions of the kernel to support various motherboards etc. So the Linux Kernel Project abandoned this model to remain competitive.
We must also balance but don't nearly have it as hard as the Linux community does since we're shielded by 2-layers of platforms (OS and Java). So we can follow our model. However note that the start was rough for us because we had to devise many experimental things from scratch.
ApacheDS is the first Java LDAP server. 1.0 was the first time this idea was put to the test. We started from scratch without previous experience or a model to follow. We just knew it could be done thanks to NIO. So many ideas needed to change. So I think we're going to be adhering much better to our scheme of releases. Also note that there will be less disparity between major releases now that we have some major issues worked out. Still though many more remain. Writing an LDAP server is more than I or anyone else ever thought. Furthermore we are trying to push LDAP to its limits and make it more usable. This is one of our primary directives. So we are dealing with concepts like Triggers and Stored Procedures. It's just as difficult if not more so to write properly than an RDBMS.
So things should get a little better for people in your place Simon as we progress towards a more mature server. Now that we've pretty much implemented the protocol its more about the other software issues that we have bandwidth to really handle properly.
We embed ADS in JBoss along with our commercial middleware product.
Our products are live in many large businesses throughout the UK and
We use DS to support Single Sign On to our browser based applications.
We use DS to manage a variety of information relating to message exchange
between 'trading partners'.
We install our products (inc. ADS) on IBM iSeries (OS400), IBM pSeries
(AIX), Solaris, HP-UX, Linux and Windows Server platforms.
- It's java and can be embedded in JBoss.
- The License allows redistribution within our product.
- It has a reliable LDAP interface so our none java product can also
- Changes between revisions are so significant it makes it difficult to
upgrade current installations.
- Persistent storage became incompatible between revisions causing
- Possible corruption of persistent storage when JVM is killed.
- 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).
- 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.
- Significant interface changes between revisions has led to regular rework
of our service container (our JBoss SAR implementation)
** I'd prefer no new features combined with a long period of stability and
However, my top two improvements would be:
- Solid, proven, replication implementation (mitosis?)
- Alternative persistence providers ( J2EE data source or JPA Provider ? )
We are a commercial entity
ADS is very good and I like and respect the guys who work so hard to
- ADS would benefit greatly from a sustained period of consolidation and
stability - no new JDKs, no more changes to public interfaces, no massive
- Fixes to ADS should be routinely applied to the stable release as well as
- I'm convinced that a well maintained, well document, long lived, stable
release is the only way ADS will gain widespread commercial implementation.
07 January 2008 16:01From: Emmanuel Lecharny <email@example.com >Subject: [Feedback needed] ADS pros and cons ?
This is the very beginning of 2008, and we are all working hard to get a
2.0 out in the next few months. At this point, we think it's a good
timing to get some feedback from you, users and developpers ! Here is a
short list of question you may answer, but this is very up to you. We
don't need names ( "I'm working for company XYZ" ), this is just
*Keep in mind that those informations will appear on the
Apache ML and many other, so if you think that any confidential piece of
it should not be disclose, then don't answer !*
1) What are you using ADS for ? Is it in production, used to do some
tests during developpement, or simply as a toy ?2) What are the Pros and Cons you clearly see ?3) What would be the major features or improvement you are expecting to
see in the near future ?4) Are you a commercial entity, an non-for profit organization, an
Apache project, a student or an individual just interested in the techno
? (no name needed)