incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ollos <ryan.ol...@wandisco.com>
Subject Re: [VOTE] Release Apache Bloodhound 0.5 (incubating)
Date Fri, 15 Mar 2013 10:45:26 GMT
On Wed, Mar 13, 2013 at 9:44 PM, Branko ─îibej <brane@wandisco.com> wrote:

> On 14.03.2013 05:32, Ryan Ollos wrote:
> > On Wed, Mar 13, 2013 at 8:52 PM, Greg Stein <gstein@gmail.com> wrote:
> >
> >> On Mar 12, 2013 1:33 PM, "Ryan Ollos" <ryan.ollos@wandisco.com> wrote:
> >>> Please let me know if you see any problems with the following plan:
> >>>  1. Leave the 0.5 tag
> >>>  2. Update the release notes, bump the version numbers to 0.5.1 and
> >> remove
> >>> the `contrib` directory on the 0.5 branch
> >>>  3. Delete the 0.5 release artifacts in the bloodhound-dist (1)
> >>>  4. Create a new release named 0.5.1
> >>>
> >>> I'll wait about 24 hours for feedback before taking any action to start
> >> the
> >>> next release.
> >> I concur with Gary: just do this on trunk.
> >>
> >> Further, I recommend calling 0.5 defunct and move to 0.6. Version
> numbers
> >> are cheap. Just note 0.5 was not released (in the release notes). You'll
> >> find similar in the svn and serf notes, where versions were pulled. I
> >> screwed up serf so badly once, we jumped from 0.3 to 0.6.1 in a few
> hours.
> >> Horrible day :-/
> >>
> > If we go this route and wish to keep milestone "Release X" aligned with
> > version "X", which I hope we do for the sake of sanity, then I'll need
> Gary
> > (or anyone else BATCH_MODIFY privileges)  to move the tickets currently
> > assigned to "Release 6" to "Release 7" (or I suppose you can accomplish
> > this in other ways that you might see fit, such as renaming milestones
> > [which is another action that I don't have permissions to perform]).
>
>
> This is ridiculous. All committers should already have permission to do
> these things in our BH instance. All PMC members should have the
> required privileges to enable these actions on any account. Whoever is
> admin now should make that happen.
>
> > I have felt that it would be less confusing to just call this release
> 0.5.1
> > and have it correspond to the "Release 5" milestone so that we don't have
> > to move tickets, but that's as much opinion as I have on the matter.
>
> Second of all, you don't have to track each and every ticket to the
> milestone in which it was released. But first of all, the issue tracking
> system we use should not dictate how we make releases.
>

Yes, I realize now that I was wrong to worry about associating "Release X"
with version 0.X. There would have been no harm in moving on to version
0.6, and it would not have required tickets to be moved.

My desire to make that association comes from wanting to have traceability
of tickets to the milestones that they were fixed in, so as stated
elsewhere, I think there is general value in having the association.
However, we wouldn't lose or gain this through the "Release X" to version
0.X association.

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