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 Thu, 19 Jul 2012 09:38:59 GMT
On 07/19/2012 02:39 AM, Olemis Lang wrote:
> 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

I have been well aware of the inconsistency of the initial release 
milestone but I preferred to leave the name alone. It could have been 
worse and I do not think there is adequate justification for renaming it 

At some point we will be concerned with where tickets associated with 
the maintenance of previous versions will be located. I suggest that 
they should go into the same release milestones so that they remain 
under the same development cycles but with the version against which 
they are developed specified. That only leaves the question of what to 
do with work arising from release. I think for now it would be enough to 
add them as blockers to the current active milestone and move them back 
into the correct milestone on actual release.


View raw message