On Thu, Aug 3, 2017 at 2:42 AM, Andy Seaborne <a...@apache.org> wrote:
> On 03/08/17 05:13, Roman Shaposhnik wrote: > >> On Wed, Aug 2, 2017 at 6:13 PM, John D. Ament <johndam...@apache.org> >> wrote: >> >>> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik <ro...@shaposhnik.org> >>> wrote: >>> >>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <a...@apache.org> wrote: >>>> >>>>> Hi all, >>>>> >>>>> In regards to the recently incubated project - Gobblin, we were >>>>> wondering >>>>> about the policy around renaming Java package names to org.apache.* Is >>>>> >>>> it a >>>> >>>>> mandatory requirement or good to have? >>>>> >>>>> The reason to ask this is that while we see many projects have migrated >>>>> >>>> to >>>> >>>>> use org.apache.* package name for their Java source files, the Kafka >>>>> project uses kafka.* for Scala sources and org.apache.kafka.* for Java >>>>> sources. >>>>> >>>>> Please let us know as soon as possible, because we are in process of >>>>> renaming the packages but if not mandatory we would want to keep >>>>> >>>> gobblin.* >>>> >>>>> package name and avoid the cost of downstream migrations and backwards >>>>> incompatibility. >>>>> >>>> >>>> You don't have to do it right away, but it is a requirement unless you >>>> have a really, >>>> really, really good reason of why you can't do that. >>>> >>>> >>>> I'm not aware of any requirement around Java package naming. IN fact, >>> last >>> time it came up it was clear that its a best practice only, and doesn't >>> have any actual naming requirements. >>> >> >> I'm not a policy wonk, but for every single podling I've witnessed this >> has been a very strong bias to be in o.a namespace. >> >> Speaking as an IPMC member I would like to see new projects migrate >> into o.a namespace unless there's a really good reason not to. >> >> Or to put it another way, if you want to avoid threads like this one: >> http://markmail.org/message/2bsrtgckuuihhnv4 >> during your graduation VOTE -- it is better to think about rename now. >> > > Jena was in a similar position with the main APIs under non o.a package > spaces. > > We waited until a major version came along and that was several years > after graduation. While it had always been the intent to change, we could > see that there was going to be major version hop due to othe factors and we > didn't want to do it twice. We did move non-API code under o.a much earlier > on an piecemeal basis. > > Jena users also have data with URI naming based on host names from our > origins in HP. We have not moved those to a.o names but encourage migration > though outputting some warnings when it is encountered and can easily > changed. > > I think it sends a positive signal to new contributors to make the package > change but it isn't always practical to do so by graduation. The user > community is already impacted by moving the mailing lists and web sites etc. > > For JVM-related projects, the maven coordinates change on entering > incubation. That is a strong enough signal. Apache Subversion created a new org.apache.subversion API, and then rebuilt our old org.tigris API on top of that. The old API is deprecated but still available. It was also a great chance to refine the API after feedback from users, and to drop ugly approaches. Much cleaner. I'd definitely recommend constructing a new API within the org.apache namespace, and deprecating the old. If you can't do it by graduation, then get it on the roadmap as a high priority. Keep the old around as (say) a separate compatibility package, layered onto the new API/naming. Cheers, -g
