esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <>
Subject Re: Release 1.0-RC2 in Jira
Date Mon, 08 Mar 2010 07:43:56 GMT

What about code changes / bug fixes that happened after the release
but weren't linked to a particular JIRA item?

How do we proceed with the 1.0 release. We are now finding a few bugs
but are mostly improvements rather than bug fixes. When do we cut the
next RC and when we do declare a real release (1.0).

On Sun, Mar 7, 2010 at 6:33 PM, Ethan Jewett <> wrote:
> Is it OK if I move all open the Jira items out of Release 1.0-RC2
> except for ESME-162 (mailto action crashes server)? I would like to
> move all of these items into Release 1.1 in Jira.
> For the closed items, I think they were mostly in Release 1.0-RC1, so
> we should leave them in RC2 in order to get them into the release
> notes. However, if there are any closed items that were fixed after
> the RC1 release, I think we should move them to release 1.1 as well.
> Ethan
> On Tue, Mar 2, 2010 at 9:31 AM, Ethan Jewett <> wrote:
>> Dick,
>> Yes, I think only bug fixes should go into 1.0 RCs. Actually, I think
>> once we get to RC stage, only really bad bugs (security, crashes) and
>> their fixes should go into the RC. All other bugs should get pushed to
>> a subsequent release.
>> Gianugo,
>> Actually, it's not orthogonal at all. It's the original topic of the
>> discussion ;-) And because of that, let's focus on topic #1 and forget
>> that I mentioned #2. Though I think it's a valid concern, I recognize
>> that if the mentors don't understand the concern, I must be missing
>> something.
>> Ethan
>> On Tue, Mar 2, 2010 at 10:00 AM, Gianugo Rabellino
>> <> wrote:
>>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <> wrote:
>>>> I only have two things to add here (assuming that this is the
>>>> definition of a release within Apache):
>>>> 1. My original concern: I think that nearly all the changes in JIRA
>>>> that are assigned to Release-1.0-RC2 should be moved to something else
>>>> called Release-1.1. We already agreed on a locked scope for release
>>>> 1.0 and I don't think we should add anything to 1.0 release candidates
>>>> aside from things we have agreed are blocking bugs. ESME-162 (mailto
>>>> actions crash the server) is probably an example of something that
>>>> should stay in Release-1.0-RC2. ESME-100 (finish Web UI) is an example
>>>> of something that should *not* stay in Release-1.0-RC2.
>>> This is a valid concern, although orthogonal to the discussion here.
>>> Still, yes, I would agree RCs should not contain any new features as
>>> they might introduce bugs or regressions.
>>>> 2. Not to pick on our mentors, but this definition doesn't make any
>>>> sense to me. It is aligned with the official Apache release definition
>>>> at but we've just moved
>>>> the question from the definition of "release" to the definition of
>>>> "the act of publishing it beyond the ESME group of developers (this
>>>> mailing list)". If this is the definition of an Apache release, then
>>>> the publicly accessible SVN repository is a release. I have a hard
>>>> time believing that if I do an export from the ESME SVN repo and
>>>> upload it to my page to facilitate testing that this
>>>> constitutes a significantly different action from sending someone
>>>> instructions on exporting the SVN repo themselves.
>>> As Richard pointed out, the real difference between "do an svn
>>> checkout -r xxx" and "grab this tarball we just released" is consensus
>>> coming from a community blessing by means of a vote. It's not peanuts,
>>> it makes all the difference.
>>>> I suggest that we work with a narrower definition. Something like "a
>>>> signed tarball published to
>>>> and advertised on the public ESME website and/or the public mailing
>>>> list is a release".
>>> You're more than welcome to argue your case, as no ASF procedure is
>>> carved in stone, but know that you should make sure you place your
>>> soapbox on front of the right audience - this is not the place to
>>> discuss what the ASF, as a whole, considers a release to be -
>>> general@incubator might be a better starting point. Until the current
>>> definition stands, so does the current process.
>>> --
>>> Gianugo Rabellino
>>> M: +44 779 5364 932 / +39 389 44 26 846
>>> Sourcesense - making sense of Open Source:

View raw message