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 <[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
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
now.
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.
Cheers,
Gary
