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