From dev-return-30964-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Tue Aug 11 13:05:17 2009 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 38365 invoked from network); 11 Aug 2009 13:05:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 11 Aug 2009 13:05:17 -0000 Received: (qmail 19047 invoked by uid 500); 11 Aug 2009 13:05:24 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 18939 invoked by uid 500); 11 Aug 2009 13:05:23 -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 18931 invoked by uid 99); 11 Aug 2009 13:05:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Aug 2009 13:05:23 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 209.85.210.180 as permitted sender) Received: from [209.85.210.180] (HELO mail-yx0-f180.google.com) (209.85.210.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Aug 2009 13:05:14 +0000 Received: by yxe10 with SMTP id 10so4344788yxe.15 for ; Tue, 11 Aug 2009 06:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=io046wruqXWoi84rpJXbhyBxLLgzpo0JslTNolp+ADk=; b=pfpR11mcaA5G4J7fCwzcIVz9BjuysN9dlHN9Es8NRGtuNzC3P/H7RySbgTgdi0t4tL J/ANsvXoTTAJJiiMhaYokGYq8cHZAsvpuuHbGoIl6FrUrTnCM988AZu2QXrLtl0WhJdg RLefQhiMbgsOISW3pL3fzCvu4rYbCrQFH1ugg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=kHpWaf3C+t8NEMvBUqdoEmxvwsM9g6ma7HlPW4r9iuS1y4xsRFKn5DKgRU8q5ttVqP V2rxu1jji0UP7VQdis3di0R/DBFu5ADtiQ4SuFjrGkXQO07tfBYxP+nKJAa1vueq5Y7O QJjKKKZXn4PjNTMgfZ3fGtBuFyvKGIQwio+nU= MIME-Version: 1.0 Sender: akarasulu@gmail.com Received: by 10.100.142.5 with SMTP id p5mr5257312and.76.1249995892322; Tue, 11 Aug 2009 06:04:52 -0700 (PDT) Date: Tue, 11 Aug 2009 16:04:52 +0300 X-Google-Sender-Auth: f5c4d2e8ff9b19de Message-ID: Subject: [ApacheDS] How about yet another versioning scheme conversation gang? From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=0016e6407b5c21f1710470dd59ec X-Virus-Checked: Checked by ClamAV on apache.org --0016e6407b5c21f1710470dd59ec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Not like we've had enough conversations that sucked up vast amounts of our time before on this topic. However after a conversation with Emmanuel I think we might have to present another approach. Current Scheme ---------------------- o We have major.minor.micro numbers. - major number denotes massive architectural shift - minor number denotes feature introductions - micro number denotes bug fixes and optimizations without changes to interfaces, db formats etc o Minor numbers were either 0 or 5. The 5 was for experimental branches with many big features being added across different releases in the branch. The 0 was for stable branches where no new features were being added but only fixes and optimizations were made. o The 0 or 5 schema came from the even/odd schema used in the older linux versioning scheme for the kernels before 2.6. We switched to 0/5 because we wanted the move from 1.0 to 1.5 to mean more than a number change but to represent the shift in JDK compatibilities. 1.5 will only run on JDK 1.5 and up. There's some good things about this schema and some bad things. 1. The scheme used takes a long time to bring about a minor release with "stable" feature additions. 2. Many of our 1.5 releases though were more stable than our 1.0 so this connotation was no longer working for us. 3. The scheme was slowing us down but hopefully (not that we could measure it) was leading to a more stable LDAP server. Not like we were building a desktop app that can get restarted to clear out leaks and such. 4. The scheme is just strange. Going from 1.0 -> 1.5 then to 2.0 is odd. What do we do go to 2.5 next? 5. What about nice little features that did not take time to do but must wait for other major features to be deemed 'stable' and usable? They don't get to the user fast enough. I'm sure lots more can be found for and against this model. But at this point with the 0/5 stuff is just odd lookin and hard to make sense of. After a convo with Emm on IRC we came up with the following new scheme: Future Scheme -------------------- o We have major.minor.micro numbers: - major number denotes massive architectural shift - minor number denotes feature introductions - micro number denotes bug fixes and optimizations without changes to interfaces, db formats etc o We bump up minor numbers whenever we add a new feature no matter how many new things were added. o We bump up micro numbers in case we make a bug fix or improvement. The idea here is to just keep bumping organically as we like. We can for example just go to 2.0.0-rc1 after 1.5.5. This seems like a natural progression to get us out of this old scheme with one last .5 increment. Then we can just keep bumping as we add feature after feature without the requirement for micro bug fix releases. So we can have a 2.1.0 then a 2.1.1 etc or just jump to 2.2.0 from 2.1.0. Up to us. This is the cool thang about it. With this freedom comes benefits to our users. They get to see features faster since we do more releases back to back. Hopefully though greater bug introduction will not be there. But this is a balanced risk we will have to take. So our releases will sort of be like what Atlassian does for example for JIRA and Confluence. Thoughts? -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org --0016e6407b5c21f1710470dd59ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not like we've had enough conversations that sucked up vast amounts of = our time before on this topic.=A0 However after a conversation with Emmanue= l I think we might have to present another approach.

Current Scheme<= br> ----------------------

=A0 o We have major.minor.micro numbers.=A0 <= br>=A0=A0=A0=A0=A0 - major number denotes massive architectural shift
= =A0=A0=A0=A0=A0 - minor number denotes feature introductions
=A0=A0=A0= =A0=A0 - micro number denotes bug fixes and optimizations without changes t= o interfaces, db formats etc
=A0 o Minor numbers were either 0 or 5.=A0 The 5 was for experimental branc= hes with many big features being added across different releases in the bra= nch.=A0 The 0 was for stable branches where no new features were being adde= d but only fixes and optimizations were made.
=A0 o The 0 or 5 schema came from the even/odd schema used in the older lin= ux versioning scheme for the kernels before 2.6.=A0 We switched to 0/5 beca= use we wanted the move from 1.0 to 1.5 to mean more than a number change bu= t to represent the shift in JDK compatibilities.=A0 1.5 will only run on JD= K 1.5 and up.

There's some good things about this schema and some bad things.
1. The scheme used takes a long time to bring about a minor release wi= th "stable" feature additions.
2. Many of our 1.5 releases tho= ugh were more stable than our 1.0 so this connotation was no longer working= for us.
3.=A0 The scheme was slowing us down but hopefully (not that we could measu= re it) was leading to a more stable LDAP server.=A0 Not like we were buildi= ng a desktop app that can get restarted to clear out leaks and such.
4. = The scheme is just strange.=A0 Going from 1.0 -> 1.5 then to 2.0 is odd.= =A0 What do we do go to 2.5 next?
5. What about nice little features that did not take time to do but must wa= it for other major features to be deemed 'stable' and usable?=A0 Th= ey don't get to the user fast enough.

I'm sure lots more can= be found for and against this model.=A0 But at this point with the 0/5 stu= ff is just odd lookin and hard to make sense of.=A0 After a convo with Emm = on IRC we came up with the following new scheme:

Future Scheme
--------------------

=A0 o We have major.minor.= micro numbers:=A0
=A0=A0=A0=A0=A0 - major number denotes massive archit= ectural shift
=A0=A0=A0=A0=A0 - minor number denotes feature introductio= ns
=A0=A0=A0=A0=A0 - micro number denotes bug fixes and optimizations wi= thout changes to interfaces, db formats etc
=A0 o We bump up minor numbers whenever we add a new feature no matter how = many new things were added.
=A0 o We bump up micro numbers in case we ma= ke a bug fix or improvement.

The idea here is to just keep bumping o= rganically as we like.=A0 We can for example just go to 2.0.0-rc1 after 1.5= .5.=A0 This seems like a natural progression to get us out of this old sche= me with one last .5 increment.=A0 Then we can just keep bumping as we add f= eature after feature without the requirement for micro bug fix releases.=A0= So we can have a 2.1.0 then a 2.1.1 etc or just jump to 2.2.0 from 2.1.0.= =A0 Up to us.=A0 This is the cool thang about it.

With this freedom comes benefits to our users.=A0 They get to see featu= res faster since we do more releases back to back.=A0 Hopefully though grea= ter bug introduction will not be there.=A0 But this is a balanced risk we w= ill have to take. So our releases will sort of be like what Atlassian does = for example for JIRA and Confluence.

Thoughts?

--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache = Directory Server :: http://director= y.apache.org
Apache MINA :: http://mina.apache.org

--0016e6407b5c21f1710470dd59ec--