Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 95333 invoked from network); 8 May 2007 13:11:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 May 2007 13:11:52 -0000 Received: (qmail 34788 invoked by uid 500); 8 May 2007 13:11:56 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 34756 invoked by uid 500); 8 May 2007 13:11:56 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 34740 invoked by uid 99); 8 May 2007 13:11:56 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 May 2007 06:11:56 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of chris.custine@gmail.com designates 209.85.132.243 as permitted sender) Received: from [209.85.132.243] (HELO an-out-0708.google.com) (209.85.132.243) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 May 2007 06:11:49 -0700 Received: by an-out-0708.google.com with SMTP id c10so201762ana for ; Tue, 08 May 2007 06:11:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=A7k6ZGi0x7fZpUNIpbCxiF3XG75toVcjv6WbeyWpT55za6UjucagyN+r0u+AuyieaQxM7WyvsVRfZest2sX+pHAKioKfyLVMuxZY6ji4nhNbuDj8lMMWxxDZ2+DFAOVen11GU82inWJkZjf5zwD8TAHq1CswEOh/qu76bJHQIYE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=NbPQ586Ac6cEhCUYtJ8hoOCubfKOn/XyX/MUyGh4CHCCYuHRE3LjhMUPYmvwZf+D3RZJH2xEfz71goDL5ex31/WQYV7rrU66amYxTd68EphhJ92N7uDUfes3PKlEzdg5bkCBQQLsl7KBMd2yErLB/KWGQXb/bQoFZlfs0PtWdwo= Received: by 10.100.212.15 with SMTP id k15mr5677448ang.1178629888035; Tue, 08 May 2007 06:11:28 -0700 (PDT) Received: by 10.100.249.15 with HTTP; Tue, 8 May 2007 06:11:27 -0700 (PDT) Message-ID: <43b026c70705080611o4f5e519en70153f4eb7873f5c@mail.gmail.com> Date: Tue, 8 May 2007 07:11:27 -0600 From: "Chris Custine" To: "Apache Directory Developers List" Subject: Re: [Version Numbering scheme] was: Version numbering and roadmap planning In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_118616_14654546.1178629887986" References: <43b026c70705031756j6107732eo24ecb9e05c55507c@mail.gmail.com> <463C7607.3050902@apache.org> <463EC88B.8010005@apache.org> <43b026c70705070857x74c6b22an1ae57d419766fc60@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_118616_14654546.1178629887986 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline > > 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 wrote: > > Hiya Chris, > > On 5/7/07, Chris Custine 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 > ------=_Part_118616_14654546.1178629887986 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
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 < akarasulu@apache.org> wrote:
Hiya Chris,

On 5/7/07, Chris Custine <chris.custine@gmail.com> 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

------=_Part_118616_14654546.1178629887986--