OK cool. Perhaps others can sound off on this approach?
Alex On 5/8/07, Chris Custine <[EMAIL PROTECTED]> wrote:
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. No this won't be a problem... On 5/8/07, Alex Karasulu < [EMAIL PROTECTED]> wrote: > > 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.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. > > > 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 >
