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 <[email protected]> wrote: > On Wed, Jul 18, 2012 at 10:06 PM, Olemis Lang <[email protected]> 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 > -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:
