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