Hiya Chris, On 5/7/07, Chris Custine <[EMAIL PROTECTED]> wrote:
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.
Yeah true. This is not a good situation to be in. 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.7beta 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.
I think I like this. So the alpha would be for feature releases that may be somewhat destabilized. The beta would be for releases that are being stabilized or optimized before a stable release? What do others think? 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.
Actually this is not an issue. I think we can release beta's as long as it is an officially voted on release. It just signifies that new features are introduced before stabilizing or hardening the server. 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.
Well the beta marker as you suggest does explicitly give a signal to the user. I like it. I hate to spend so much time on this type of subject, This is very good tho - you're helping us answer some critical questions. 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...
This is a good suggestion really. Oh btw will this impose any issues with OSGi versioning? Just thought I'd ask that. Don't know what happens with the beta/alpha designators. Alex
