bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: Milestone names in issue tracker matching version number in deliverables
Date Thu, 19 Jul 2012 01:39:20 GMT
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 <> wrote:
> On Wed, Jul 18, 2012 at 10:06 PM, Olemis Lang <> 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 (<= 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 «RC1 for initial
>> release» 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 to
> 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 iteration
> 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 be
> 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 compensate
> if necessary. The roadmap therefore is not a strict guide to when a feature
> 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 and
> 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 would
> therefore be a maximum of a month away.
> I hope this sounds reasonable.
> Cheers,
>     Gary



Blog ES:
Blog EN:

Featured article:

View raw message