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 >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> > >
