Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of olemis@gmail.com designates
 209.85.214.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAEZ-ge7PhcOSTZxB+oKEbXVvJovwCwM9v57pXGapGKLyBKrB1w@mail.gmail.com>
References: 
 <CAGMZAuOK08y79RLLS7u=e9aT1QdJQdt9APPQwvB1vzNtgYTeSg@mail.gmail.com>
	<CAEZ-ge7PhcOSTZxB+oKEbXVvJovwCwM9v57pXGapGKLyBKrB1w@mail.gmail.com>
Date: Wed, 18 Jul 2012 21:39:20 -0400
Message-ID: 
 <CAGMZAuO4a9KDnDCpCRcnFvB1ctMGrq_LGsBq70nXw=DJvSU2LA@mail.gmail.com>
Subject: Re: Milestone names in issue tracker matching version number in
 deliverables
From: Olemis Lang <olemis@gmail.com>
To: bloodhound-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Gary !

Maybe it was not clear in my previous message because I did not
mention , but I was referring to RC1 ;)

but it's ok . Your suggestion seems to be better . As long as there's
a way to associate tickets related to some deliverable, it's ok for me
.

On 7/18/12, Gary Martin <gary.martin@wandisco.com> wrote:
> On Wed, Jul 18, 2012 at 10:06 PM, Olemis Lang <olemis@gmail.com> wrote:
>
>> This is a simple and straightforward (afaics) request . Is it possible
>> to set names for milestones in the issue tracker matching the version
>> number of the artifacts released by the project . Any other similar
>> way to easily know what got committed in which deliverable artifact
>> would be welcome (<=3D IMO) . For instance , it might not be clear for
>> somebody not familiar with the work been done that released file
>> apache-bloodhound-0.1.0 contains the changes bound to =ABRC1 for initial
>> release=BB milestone .
>>
>> Thanks for your time ...
>>
>
> Well, if we are going to move to a model of frequent, short time frame
> releases, I do not think it will be strictly possible or necessary to
> predetermine version numbers. Unless there are objections, we are going t=
o
> attempt to release on a regular basis. In each of these iterations the
> associated milestone will look at implementing specific features, along
> with continuing improvements we want to see. If at the end of the iterati=
on
> we have not added major features then, for the example of the Release 2
> milestone, we will release as 0.1.1 and otherwise we will move to 0.2.0.
>
> So, for the moment I am suggesting that we stick with the predictable
> "Release n" milestone names and the point at which the milestone becomes =
an
> official release, we migrate the milestone to a version with the correct
> name. The milestone we are working on will always be obvious as it will b=
e
> the lowest numbered open milestone.
>
> At the end of an iteration, any features that were planned for it will be
> moved on to the next milestone and future milestones adjusted to compensa=
te
> if necessary. The roadmap therefore is not a strict guide to when a featu=
re
> will definitely arrive but hints at the expected order.
>
> At the moment I am suggesting that we prepare a release every three weeks=
.
> I expect us to generally split this into two weeks of solid development a=
nd
> one of consolidation. This is not specifically to stop any person from
> continuing to work on new features in the consolidation time but it might
> be decided that such work would contribute to the next release. This woul=
d
> therefore be a maximum of a month away.
>
> I hope this sounds reasonable.
>
> Cheers,
>     Gary
>


--=20
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article: