Ah ! got it. On Wed, May 24, 2017 at 9:46 AM, larry mccay <[email protected]> wrote:
> Actually, what I am proposing is that we *branch* on Monday and double > commit as necessary in order to close down before the rc and through the > release process. I'd like to get to a rc by the end of next week - 6/2 - if > not sooner. > > We will also likely need to double commit bug fixes to master and 0.13.0 > branch for some time in case we need a new 0.13.x release to avoid the > 1.0.0 refactoring for existing deployments. > > On Wed, May 24, 2017 at 9:29 AM, Sandeep More <[email protected]> > wrote: > >> Hello Larry, >> >> Thanks for starting the discussion, given that we are away from the >> target date just by a week I too think that releasing 0.13.0 on Monday and >> then working towards 1.0.0 (package refactoring) would be a good idea. One >> upshot of this is that we don't have to double commit as we had initially >> thought :) >> >> Best, >> Sandeep >> >> On Tue, May 23, 2017 at 4:44 PM, larry mccay <[email protected]> wrote: >> >>> All - >>> >>> As we targeted a 5/31 date for the release of 0.13.0, I think we need to >>> look at managing the current scope for 0.13.0 as well as the plan for a >>> 1.0.0 again. >>> Since we are just a week away from the target date, I think that >>> refactoring the package names for the 1.0.0 release at the same time is a >>> stretch. >>> >>> We currently have 22 or so JIRAs and will not be able to get them all >>> into 0.13.0. >>> What do you think about the following: >>> >>> * We manage the existing scope over the rest of this week. >>> * I will post comments on some JIRAs about potentially moving them out >>> and without any movement will move them out by Friday 26th. >>> * JIRAs that I think are outside the KIPs that are driving the release >>> or that may destabilize the release I will just move. >>> >>> If I move something that is something wanted by you, please feel free to >>> add it back, comment or raise discussion on this thread. >>> >>> I also propose that we branch for 0.13.0 on Monday 5/29th and work >>> toward getting the rest of the required issues in and an RC by the 31st or >>> by end of the week. Once we release 0.13.0, we should refactor master for >>> the 1.0.0 release - concentrate on closing down any fallout from package >>> name changes and do an immediate 1.0.0 release. >>> >>> Thoughts? >>> >>> thanks, >>> >>> --larry >>> >>> >>> On Thu, Apr 27, 2017 at 1:32 PM, Sandeep More <[email protected]> >>> wrote: >>> >>>> Sounds great ! >>>> >>>> On Thu, Apr 27, 2017 at 12:32 PM, larry mccay <[email protected]> >>>> wrote: >>>> >>>> > That sounds reasonable to me. >>>> > I was hoping to get as many of the patches available and important >>>> bugs >>>> > fixed before the split as well. >>>> > Minimizing the double commits/patches is definitely in our interest. >>>> > >>>> > At the same time, we need to have enough time to spend on refactoring >>>> as >>>> > well. >>>> > I'm thinking that May 15th may be a good branch point - giving us 2 >>>> weeks >>>> > to concentrate on repackaging and adapter classes. >>>> > >>>> > >>>> > On Thu, Apr 27, 2017 at 12:16 PM, Sandeep More <[email protected] >>>> > >>>> > wrote: >>>> > >>>> > > Oh, I guess it depends on when we split, I was planning on taking >>>> up the >>>> > > new feature (mentioned in earlier email). >>>> > > If we decide to go for the feature I was hoping to get it in sooner >>>> > (before >>>> > > the split) if possible. >>>> > > >>>> > > >>>> > > On Thu, Apr 27, 2017 at 11:53 AM, larry mccay <[email protected]> >>>> wrote: >>>> > > >>>> > > > Actually, I meant 5/31 for a release date. >>>> > > > You think that is too early for a repackaged and narrowly scoped >>>> 1.0.0? >>>> > > > >>>> > > > On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More < >>>> [email protected]> >>>> > > > wrote: >>>> > > > >>>> > > > > Great, thanks Larry for starting the discussion and the KIP ! >>>> > > > > >>>> > > > > May 31st target date sounds good, just to be sure, this date is >>>> when >>>> > we >>>> > > > > split 0.13 right ? >>>> > > > > >>>> > > > > KIP-5 looks good, I will try to see whether I can find any >>>> extended >>>> > > > classes >>>> > > > > that might need adapter classes. >>>> > > > > >>>> > > > > Best, >>>> > > > > Sandeep >>>> > > > > >>>> > > > > On Thu, Apr 27, 2017 at 11:35 AM, larry mccay < >>>> [email protected]> >>>> > > wrote: >>>> > > > > >>>> > > > > > Forgot to add the [1] to the initial mail. >>>> > > > > > >>>> > > > > > Enjoy... >>>> > > > > > >>>> > > > > > 1. >>>> > > > > > http://mail-archives.apache.org/mod_mbox/knox-dev/201704. >>>> > > > > > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T- >>>> > > > > rFEHJG6G5sB4Q%40mail.gmail. >>>> > > > > > com%3E >>>> > > > > > >>>> > > > > > >>>> > > > > > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay < >>>> [email protected]> >>>> > > > wrote: >>>> > > > > > >>>> > > > > > > All - >>>> > > > > > > >>>> > > > > > > After many recent distractions, I would like to start the >>>> scoping >>>> > > and >>>> > > > > > > planning for what will likely be our 1.0.0 release. >>>> > > > > > > >>>> > > > > > > As discussed in [1], we will begin to repackaging/refactor >>>> master >>>> > > > after >>>> > > > > > > branching for an 0.13.0 release and only release 0.13.0 if >>>> the >>>> > work >>>> > > > on >>>> > > > > > > repackaging master doesn't seem like it will make whatever >>>> date >>>> > we >>>> > > > > chose >>>> > > > > > > for the release. >>>> > > > > > > >>>> > > > > > > That said, I would like to limit scope to only those new >>>> features >>>> > > and >>>> > > > > bug >>>> > > > > > > fixes that are absolutely necessary or low risk for breaking >>>> > > backward >>>> > > > > > > compatibility. >>>> > > > > > > >>>> > > > > > > I propose that the following is needed: >>>> > > > > > > >>>> > > > > > > * A KIP (KIP-5) be created for the repackaging/refactoring >>>> work >>>> > > > > required >>>> > > > > > > for the 1.0.0 release >>>> > > > > > > * Determine the existing JIRAs and patches that must/can be >>>> in >>>> > the >>>> > > > > > release >>>> > > > > > > but try and defer as many as possible >>>> > > > > > > * Determine required improvements - I have a few security >>>> related >>>> > > > > > > improvements in mind >>>> > > > > > > * Write up KIPs for features that involve architectural >>>> and/or >>>> > > > > strategic >>>> > > > > > > feature details >>>> > > > > > > * Determine when to branch for 0.13.0 and take on double >>>> commits >>>> > > for >>>> > > > > > 1.0.0 >>>> > > > > > > parity >>>> > > > > > > * Agree on a target release date >>>> > > > > > > >>>> > > > > > > My initial thought is to target May 31st as the release >>>> date. >>>> > > > > > > >>>> > > > > > > Thoughts? >>>> > > > > > > >>>> > > > > > > --larry >>>> > > > > > > >>>> > > > > > >>>> > > > > >>>> > > > >>>> > > >>>> > >>>> >>> >>> >> >
