Plans for the Next Apache Knox Release

2014-08-05 Thread larry mccay
Folks - I think it is time that we begin talking about the next release for Apache Knox. There are quite a few fixed and outstanding jiras that would be candidates for this release. We will need to determine a couple things: 1. Version numbering for the release. I believe that we have a couple

Re: Plans for the Next Apache Knox Release

2014-08-05 Thread Kevin Minder
One important consideration for our next release should be changing at least our maven groupId and possibly our package structure to org.apache.knox. I had always considered this a step we would take as part of a 1.0 release. On 8/5/14 12:24 PM, larry mccay wrote: Folks - I think it is time

Re: Plans for the Next Apache Knox Release

2014-08-05 Thread larry mccay
Yes - that is a good point and should be done regardless of version designation but certainly if we are to go with a 1.0. On Tue, Aug 5, 2014 at 12:37 PM, Kevin Minder wrote: > One important consideration for our next release should be changing at > least our maven groupId and possibly our pack

Re: Plans for the Next Apache Knox Release

2014-08-05 Thread Kevin Minder
Should we consider the maven groupId change separately from the package name change? On 8/5/14 1:58 PM, larry mccay wrote: Yes - that is a good point and should be done regardless of version designation but certainly if we are to go with a 1.0. On Tue, Aug 5, 2014 at 12:37 PM, Kevin Minder w

Re: Plans for the Next Apache Knox Release

2014-08-05 Thread larry mccay
Seems like they should be done at the same time to me. Is there some reason that they should be separated in terms of risk of completion or something else? On Tue, Aug 5, 2014 at 1:59 PM, Kevin Minder wrote: > Should we consider the maven groupId change separately from the package > name chang

Commits should include CHANGES.txt update

2014-08-05 Thread larry mccay
Folks - I feel as though we should uptake the policy that is used for Hadoop common commits where every commit includes a record of the change in CHANGES.txt. This will make the release process easier since we won't have to backfill all of the changes at release candidate creation time. Also, as

Re: Commits should include CHANGES.txt update

2014-08-05 Thread Kevin Minder
This makes sense to me and isn't too much overhead. On 8/5/14 4:30 PM, larry mccay wrote: Folks - I feel as though we should uptake the policy that is used for Hadoop common commits where every commit includes a record of the change in CHANGES.txt. This will make the release process easier sin