My main concern with all of the implied meaning in the release numbers is that the users will not pay attention to it, and eventually get irritated with it when they have an issue with a new feature and we tell them that they probably shouldn't play with their shiny new toy in production.
Last night it occured to me that maybe we have all overlooked an obvious solution that could make everyone happy. With the unstable feature releases we are basically talking about a very formal beta testing phase. So maybe we should call these releases beta releases, but without any special meaning embedded in the numbers. So after a stable release of 1.6, why don't we do the typical release branch for bugfixe releases like 1.6.1, work off of the trunk for the next major release and do releases from trunk as 1.7 beta 1, 1.7 beta 2, etc. until things are stable. Or at least something along these lines. I think this will make much more sense to the users and allows the Directory project to introduce new features in beta releases without worry of tripping up any bleeding edge users using beta releases.
There are a couple of small drawbacks. Even though I see other projects doing it, we shouldn't release beta builds on the main maven repo, although I am not sure this is a hard rule, I think it is a general practice not to do it.
However this leads back to the main argument that the special unstable build numbers are misleading when deployed to maven repos because the user may not realize what the build number means and could use it in a production app.
I hate to spend so much time on this type of subject,
but I just want to make sure that the users see things clearly and that we don't impose any special rules on them with released versions. The beta solution may not be the prettiest, but there is a lot of precedent with other projects and vendor products out there and at least this way the users know exactly what they are getting when they download and install ;-) So consider this just another suggestion...