incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: Milestone names in issue tracker matching version number in deliverables
Date Wed, 18 Jul 2012 23:20:47 GMT
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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message