I have been reading through the release notes (I know that we will be making changes to them as needed). Should we branch for the release "0.2-dev" and tag "0.2.0" so that we know what was in the release? Or should we branch each time? So that "0.2.0" is a branch, and we branch from "0.2.0" to make "0.2.1"?
On side a note, I think that unless there is a bug fix needed for "0.2.0" that we should just work toward "0.3.0" and have that release within a month. What do you all think? Aaron On Wed, Sep 4, 2013 at 9:16 AM, Aaron McCurry <[email protected]> wrote: > Awesome thanks Chris! And good luck! > > Aaron > > > On Wed, Sep 4, 2013 at 9:10 AM, Chris Rohr <[email protected]> wrote: > >> I just commented on the Blur Console ticket with the last remaining items >> that don't work. I can try to fix them tonight (assuming my wife doesn't >> go into labor). >> >> Chris >> >> On Sep 4, 2013, at 6:55 AM, Aaron McCurry <[email protected]> wrote: >> >> > That is good with me. I do have one request. Can I leave the factory >> code I put in to allow for the creation of the block cache? It's pretty >> harmless code and has no effect on configuration. Once I remove the v2 >> block cache I think we can consider a code freeze. >> > >> > Aaron >> > >> > Sent from my iPhone >> > >> > On Sep 3, 2013, at 11:14 PM, Tim Williams <[email protected]> wrote: >> > >> >> I meant to add, I reckon this'd mean we'd pull back the block cache-v2 >> >> stuff for this release... >> >> >> >> On Tuesday, September 3, 2013, Tim Williams wrote: >> >> >> >>> I've been editing HowToRelease[1] in anticipation of an upcoming >> >>> release. I'd like to propose instead that we just do the release and >> >>> edit that with the commands/procedures that we actually perform. The >> >>> rationale is that some of preferred methods have changed (e.g. >> >>> svn-based vs. p.a.o/dist) and it'd be easiest for the RM to just >> >>> update it as they go along. >> >>> >> >>> Are there any open issues blocking a release? >> >>> >> >>> Can we consider a code-freeze on master for a couple days? >> >>> >> >>> If no to both, any problems with creating a release candidate tomorrow >> >>> and letting it run 72hrs? >> >>> >> >>> Or, an alternate proposal? >> >>> >> >>> Thanks, >> >>> --tim >> >>> >> >>> [1] - https://wiki.apache.org/blur/HowToRelease >> >>> >> >> >
