And remember: like Apache Subversion, the project can keep a *compatibility* layer around using the old name. But "all" new development work would occur under the new org.apache name...
On Thu, Aug 3, 2017 at 11:34 AM, John D. Ament <johndam...@apache.org> wrote: > One caveat - if your packages are "com.theoldcompany.someproject" they > should be renamed to "org.apache.someproject" before graduation. If you > have "org.someproject" already or just "someproject" as your package names, > that's not a naming issue so I don't see that ever blocking graduation. > > John > > On Thu, Aug 3, 2017 at 12:25 PM Alex Harui <aha...@adobe.com.invalid> > wrote: > > > OK, so to summarize a more refined recommendation: > > > > 1) package names with reverse domains MUST be renamed before graduation > or > > have an IPMC approved plan for renaming > > 2) Projects who expect that their future users outnumber current users > are > > highly encouraged to rename packages > > 3) Other projects are not required to rename packages and backward > > compatibility is sufficient reason to not rename packages. > > > > Or should #2 also be a MUST? > > > > -Alex > > > > On 8/3/17, 8:34 AM, "Andy Seaborne" <a...@apache.org> wrote: > > > > > > > > > > >On 03/08/17 15:51, Julian Hyde wrote: > > >> It rarely comes down to the IPMC or the Board dictating how a project > > >>names its java classes (does anyone recall an instance?), so it’s > mainly > > >>the project’s discretion. In my opinion, where the project is on its > > >>adoption curve is an important consideration. > > > > > >+1 > > > > > >> Most projects that enter the incubator are early on the adoption > curve. > > >>Their future users outnumber their current users. The earlier these > > >>projects make the change to org.apache, the fewer people they will > > >>ultimately impact. It seems that gobblin is in this category. > > >> > > >> A few projects, such as Flex, are already near the top of their > > >>adoption curve. The cost/benefit of renaming is not as compelling. > > > > > >Jena was not early on the adoption curve. Long term compatibility has > > >been, and is, a major element of the project culture. Importantly, > > >there are active users who answer questions (here, elsewhere), external > > >web tutorials, books etc referring to the pre-ASF API. We have a > > >responsibility to them as well. > > > > > >"add an API" is more stuff that a small set of volunteer contributors > > >(Jena has had no paid contributors working on) could not have coped > > >with. If a project has the capacity, sure. Not all project will. > > > > > >Set the expectations too high and it is implicitly a filter for a > > >certain kind of project in size and structure. > > > > > > Andy > > > > > > > > >> > > >> Julian > > >> > > >> > > >>> On Aug 3, 2017, at 7:37 AM, Alex Harui <aha...@adobe.com.INVALID> > > >>>wrote: > > >>> > > >>> From the peanut gallery: > > >>> > > >>> Does the PPMC get to decide what constitutes a "very good reason" or > > >>>does > > >>> the IPMC and after graduation, the board? > > >>> > > >>> Flex has not changed its packages in the 5 years at Apache. We felt > > >>> backward compatibility was and is a "very good reason". It was way > > >>>more > > >>> important to not require folks to alter their code in order to move > to > > >>>the > > >>> Apache versions of Flex. Also, we are not using Java/Maven so there > > >>>isn't > > >>> really a shading option. > > >>> > > >>> On the other hand, it seems like it could be confusing for Apache > > >>>projects > > >>> to have packages starting with "com.". Flex's packages start with > > >>>"mx" or > > >>> "spark" (the component set names). > > >>> > > >>> Seems like a more refined guidance would be that: > > >>> 1) packages starting with "com" (and maybe > > >>>org.somethingOtherThanApache) > > >>> should be changed as soon as possible/practical > > >>> 2) there is no recommendation for other package prefixes > > >>> > > >>> My 2 cents, > > >>> -Alex > > >>> > > >>> On 8/3/17, 5:42 AM, "Shane Curcuru" <a...@shanecurcuru.org > > >>><mailto:a...@shanecurcuru.org>> wrote: > > >>> > > >>>> John D. Ament wrote on 8/2/17 9:13 PM: > > >>>>> 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. > > >>>> > > >>>> John: Do you have a link to that discussion? I'm of the mind that > > >>>>it's > > >>>> an expected best practice, unless you have a really, really good > > >>>>reason > > >>>> otherwise. > > >>>> > > >>>> Abhishek: Can you describe in more detail what these packages do in > > >>>>the > > >>>> context of your software product? > > >>>> > > >>>> In general, yes, I'd echo Roman's point strongly for the primary > > >>>> external API that most users would call: > > >>>> > > >>>>>> Or to put it a different way: during your eventual graduation this > > >>>>>> question will be > > >>>>>> asked and you better have a really, really good explanation if > > >>>>>>you're > > >>>>>> still using > > >>>>>> something other than o.a. > > >>>> > > >>>> That is, supporting packages, or things that are standards, or > things > > >>>> that are specific plugins that integrate with external code - those > I > > >>>> could understand staying with a non-a.o package name for > compatibility > > >>>> or other reasons. > > >>>> > > >>>> But the main program that users run in the JVM, or the primary > Gobblin > > >>>> classes that users integrating the code into their application? > That > > >>>> should be in an org.apache.gobblin.* package. > > >>>> > > >>>> Simple "backwards compatibility for users" as an argument is only > > >>>> suitable if you're deprecating and have a plan to switch in the > > >>>> reasonably-near future after graduation. Not for the long term. > > >>>> > > >>>> Thanks for raising the question early! > > >>>> > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Roman. > > >>>> > > >>>> -- > > >>>> > > >>>> - Shane > > >>>> > > >>>> > > >>>> > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ap > > >>>>ach > > >>>>< > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.a > > >>>>pach> > > >>>> e.org > > >>>>< > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fe.org% > > >>>>2F&data=02%7C01%7C%7C581cf191f4d745137c4008d4da85 > 30d6%7Cfa7b1b5a7b34438 > > >>>>794aed2c178decee1%7C0%7C0%7C636373712971951815&sdata=aY% > 2BocRBKdLSJNW7r > > >>>>0X4YnZ239BbsJWprJgTncaEESNQ%3D&reserved=0>%2Ffoundation% > 2Fmarks%2Fresou > > >>>>rces&data=02%7C01%7C%7Cef18c5e74b0141378 > > >>>> > > >>>>79a08d4da6d0e5c%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C6363736093 > > >>>>056 > > >>>> > > >>>>90124&sdata=OyrEoidSvoONvFJksGYjhhz%2FatAd4b%2FyjmHcfoGeI%2B0%3D& > reserv > > >>>>ed= > > >>>> 0 > > >>>> > > >>>> ------------------------------------------------------------ > --------- > > >>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > >>>><mailto:general-unsubscr...@incubator.apache.org> > > >>>> For additional commands, e-mail: general-h...@incubator.apache.org > > >>>><mailto:general-h...@incubator.apache.org> > > >>>> > > >>> > > >>> > > >>> ------------------------------------------------------------ > --------- > > >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > >>><mailto:general-unsubscr...@incubator.apache.org> > > >>> For additional commands, e-mail: general-h...@incubator.apache.org > > >>><mailto:general-h...@incubator.apache.org> > > >> > > > > > >--------------------------------------------------------------------- > > >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > >For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > >
