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: <4490E34C.6090305@hogstrom.org>
Date: Thu, 15 Jun 2006 00:34:20 -0400
From: Matt Hogstrom <matt@hogstrom.org>
User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516)
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>
In-Reply-To: <af2843cd0606141039o2083d01dpf17d18bfad180764@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.
> 
>