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 <moresand...@gmail.com> wrote: > Sounds great ! > > On Thu, Apr 27, 2017 at 12:32 PM, larry mccay <lmc...@apache.org> 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 <moresand...@gmail.com> > > 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 <lmc...@apache.org> > 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 < > moresand...@gmail.com> > > > > 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 <lmc...@apache.org> > > > 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 <lmc...@apache.org > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
