Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <4491B60B.4000208@toolazydogs.com>
Date: Thu, 15 Jun 2006 12:33:31 -0700
From: "Alan D. Cabrera" <list@toolazydogs.com>
User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Thoughts about what a release is
References: <448C6A63.8010306@hogstrom.org> <448CB880.1080407@toolazydogs.com>
 <af2843cd0606141039o2083d01dpf17d18bfad180764@mail.gmail.com>
 <4490E34C.6090305@hogstrom.org> <44915E2C.3060301@yahoo.com>
In-Reply-To: <44915E2C.3060301@yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Donald Woods wrote:
> I have to agree with Matt - wrapping the container as a GBean and then 
> letting the container do its job is the least obtrusive for existing 
> users.  
I'm not sure where Matt's message implies this. 
> Why must we turn everything into a GBean?  We already make things 
> difficult for existing Tomcat users and developers who want to move 
> their skills and apps over to Geronimo.  Why should we do the same for 
> every other service we add into the server?
I, and people who started XBean, feel the same way.  IIUC, this will be 
cleaned up in 1.2.


Regards,
Alan
>
>
> -Donald
>
>
> Matt Hogstrom wrote:
>> Not sure if this is already captured.
>>
>> What do folks think about leaving the modules as independent pieces 
>> with their own version numbers and the geronimo_version is just the 
>> aggregate release to users?  I expect this would make out life more 
>> difficult but I haven't found the single version number to rule all 
>> modules all that easy either.
>>
>> Also, it would be nice that if a module hadn't changed then it stays 
>> static and is a good indicator of where the activity is.
>>
>> Thoughts?
>>
>> Hiram Chirino wrote:
>>
>>> On 6/11/06, Alan D. Cabrera <list@toolazydogs.com> wrote:
>>>
>>>>
>>>>   X.Y.z:  patch release - bug fixes
>>>>   X.y:    minor release - bug fixes and compatible enhancements
>>>>   x:      major release - major enhancements, and incompatible changes
>>>>
>>>>
>>>> I am very much against placing anything but patches in the .z 
>>>> releases.
>>>> Let me explain why.  When we make a minor release we basically branch
>>>> the X.y release for the purposes of  releasing patches.  Any 
>>>> changes to
>>>> this branch, e.g. patches, must also be immediately applied to the
>>>> trunk.  If we make any enhancements to this branch, we must also
>>>> immediately apply the same enhancement to that branch.  This adds
>>>> significant more risk that bug patching but more importantly when we
>>>> fall into the trap of putting minor enhancements into a patch release,
>>>> we remove the most serious impetus to getting the minor release 
>>>> done and
>>>> out the door.
>>>>
>>>
>>> +1.  This allows us to time box the bug fix releases.  If we can get
>>> into the groove of doing regular x.y.z releases (at  like 1 a month
>>> intervals), then I think that also reduces the pressure on needing to
>>> make the x.y releases perfect.  I think we sometimes delay our x.y
>>> releases because we are aiming for perfection.
>>>
>>> The only problem with the above is that it does not solve the problem
>>> of being able to time box the x.y release.  The since dev branch of
>>> the x.y release could have multiple new features at different levels
>>> of completion it's hard to stabilize at any given time.  Do you guys
>>> consider this a problem?
>>>
>>> I like Dain's suggestion of splitting up the modules.  In theory in
>>> progress work being done separately versioned project should not hold
>>> up the time boxed release of a Geronimo x.y. Geronimo would just
>>> release with the previous stable version.  In practice, even for
>>> independently versioned projects like ActiveMQ, Geronimo will hold up
>>> it's releases to get new releases from ActiveMQ. This is bad if you
>>> want to time box a release.
>>>
>>> Another thought that might help Geronimo be able to stay on a time box
>>> release cycle is making more use of 'development' branches.  We could
>>> encourage develops to work on new features in development branches
>>> that get merged in once the feature is fully working.  The down side
>>> to this is that it may not be obvious to other developers what work is
>>> going on where.
>>>
>>> Or perhaps we need to do a a combination of independent versioned
>>> modules where most of the work happens, and then having small
>>> development branches of the main Geronimo module that holds the
>>> integration code that enables the new features.  So then then
>>> development branches are used to do integration testing with in
>>> progress features and they are merged in to trunk once the feature is
>>> done and all integration testing is completed.
>>>
>>>
>>
>>