directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [release][VOTE] Releasing MINA 0.7.1
Date Sun, 15 May 2005 18:56:04 GMT
David Boreham wrote:

> Alex Karasulu wrote:
>> Sorry could not get to this earlier due to tech difficulties...
>> Anyway I think it's time for the MINA release as well: +1
> -1 from me. I'd like to see the memory leaks fixed before releasing.
> In our experience the leaks in MINA make Apache DS almost
> unusable.
> I believe Elliot will be posting some patches that fix the bigger 
> leaks soon.

Well if its within the week let's wait. 

However I'd like to take this opportunity to clear up some potential 
misunderstanding or miscommunication regarding our version numbers.  
This release is not a stable (production grade) release.  A memory leak 
is just fine for odd minor numbered releases.  I know how that sounds.  
Users should however be aware of the experimental nature of such 
releases.  So once again for the record, all releases with odd minor 
numbers are experimental feature releases whereas even ones are stable 
releases.  The idea is to release features to the public quickly so you 
get feedback faster. 

IMHO this community is not releasing with enough frequency.  Code that 
is changing the most frequently due to new features should be releasing 
the most frequently.  So I completely see how users can be mislead 
thinking every release is a major event even if it's on a minor number.  
We need to encourage more feature releases even if performance is 
suboptimal.  I want to make sure this community does not get too uptight 
with new feature releases.  MINA especially has held back a release for 
way too long.  It's too good to be having its first external release 
now.  New features are appearing all over MINA as it evolves: we need 
the greater public at large (those without svn and maven experience ;) ) 
to play with them and provide feedback.  That's what minor releases are 
all about.

If this leak was in a 0.8 then I would completely agree with your 
objection.  I know I'm beating a dead horse but just to be clear I want 
to give another example.  If 0.8 was released already and you found this 
bug then we would branch the 0.8 tag and patch it with your bug fix.  
Hence a 0.8.1 release would occur if the bug is really severe.  I just 
want to drive home the fact that once a stable release is made, no new 
features are introduced in that branch: just bug fixes are.

Now back to the mem leak ... I'd like to to see the leaks gone too 
especially if the problem has already been isolated and patches for a 
fix are comming soon.  If you can get a test case and patch into a JIRA 
within the week we can hold the release until the testcase confirms the 
leaks, the patch is evaluated, and applied.  Otherwise let's make the 
changes in another release like 0.7.2.  Nothing stops us from releasing 
0.7.2 a few weeks later.  It's all good :).


View raw message