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 18:48:14 GMT
Sounds good to me.

Why don't we wait a week or two to see if anything else pops up and
then cut a new release.


On Mon, Mar 8, 2010 at 6:28 PM, Ethan Jewett <> wrote:
> Sound good to me. Looks to me like this last one was revision 918616
> and the mailto issue was revision 917187.
> So our release 1.0 would be the snapshot frozen in the 1.0-RC1 tag,
> plus these two changes. Does that sound right to everyone?
> Thanks,
> Ethan
> On Mon, Mar 8, 2010 at 11:07 AM, Richard Hirsch <> wrote:
>> I'd also like to include the exception that Vassil fixed - look at the
>> esme-dev mailing list thread "Strange Exception on Streams Page"
>> D.
>> On Mon, Mar 8, 2010 at 5:29 PM, Ethan Jewett <> wrote:
>>> I'd say that they shouldn't go in as a rule. There are always
>>> exceptions, but checking in new changes generally destabilizes the
>>> release. Based on what I see in Jira, the only code change I'd like to
>>> see in 1.0-RC2 or 1.0 would be the mailto fix.
>>> I think that with the mailto fix, we could just release 1.0 (not
>>> another RC) at this point and then concentrate on a 1.1 release with
>>> the new UI.
>>> Ethan
>>> On Mon, Mar 8, 2010 at 1:43 AM, Richard Hirsch <>
>>>> OK.
>>>> 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 <>
>>>>>> 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)
>>>>>> their fixes should go into the RC. All other bugs should get pushed
>>>>>> a subsequent release.
>>>>>> Gianugo,
>>>>>> Actually, it's not orthogonal at all. It's the original topic of
>>>>>> 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 <>
>>>>>>>> I only have two things to add here (assuming that this is
>>>>>>>> definition of a release within Apache):
>>>>>>>> 1. My original concern: I think that nearly all the changes
>>>>>>>> that are assigned to Release-1.0-RC2 should be moved to something
>>>>>>>> called Release-1.1. We already agreed on a locked scope for
>>>>>>>> 1.0 and I don't think we should add anything to 1.0 release
>>>>>>>> aside from things we have agreed are blocking bugs. ESME-162
>>>>>>>> actions crash the server) is probably an example of something
>>>>>>>> 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
>>>>>>> Still, yes, I would agree RCs should not contain any new features
>>>>>>> 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
>>>>>>>> at but we've
just moved
>>>>>>>> the question from the definition of "release" to the definition
>>>>>>>> "the act of publishing it beyond the ESME group of developers
>>>>>>>> mailing list)". If this is the definition of an Apache release,
>>>>>>>> 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
>>>>>>>> upload it to my page to facilitate testing
that this
>>>>>>>> constitutes a significantly different action from sending
>>>>>>>> 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
>>>>>>> coming from a community blessing by means of a vote. It's not
>>>>>>> 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
>>>>>>>> list is a release".
>>>>>>> You're more than welcome to argue your case, as no ASF procedure
>>>>>>> carved in stone, but know that you should make sure you place
>>>>>>> soapbox on front of the right audience - this is not the place
>>>>>>> discuss what the ASF, as a whole, considers a release to be -
>>>>>>> general@incubator might be a better starting point. Until the
>>>>>>> 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