Consideration of end user impact is a great point, and perhaps the most important consideration. In the case of DataFu, others have brought up that the rename would be a backwards-incompatible change that breaks all existing client scripts that use DataFu, and going forward such a change would cause extra low-value typing in a scripting language that's targeted to serving non-programmers. I think this makes a compelling argument for preserving the existing names in DataFu. For another project where the package names are entirely an implementation detail and not user-facing, doing the rename is not likely to cause impact.
Thanks for bringing up the topic, Matt. --Chris Nauroth On 8/10/15, 2:22 AM, "Stian Soiland-Reyes" <st...@apache.org> wrote: >I think you should consider the impact and potential gain on a >per-project basis, and agree this within the podling. I don't think we >can prescribe one way or the other for every project. > > >Changing the package name can for Java developers be a bit of an >identity thing and help to level the playing field if a strong >commercial actor is still involved. Removing >com.proprietarycompany.projectname can be more important than removing >a neutral org.projectname. > > >A more user-fronting project (e.g. a GUI or self-contained server) >face less impact on renaming than a project with many compile-bindings >outside the project (e.g. Hadoop). > > >For the Taverna incubator (which can't be reliably placed on such an >axis with a GUI+server and many external plugins), we decided that as >we were moving to Apache at the same time as we were getting ready for >3.0 with a different plugin system anyway, then this was a good time >(and perhaps the only time) to do package rename. > >But for our project, which had numerous git repositories, Maven >modules and OSGi configurations (and was due some refactoring), a Java >package rename and restructuring was a bit more work than a quick sed >and folder move, and left the codebase in non-compilable flux for >several months and took away focus from community building. > >On the other hand, this was a good exercise for engaging the whole of >the PPMC in taking responsibility for all of the code base - for our >project we had a history of divide-and-conquer responsibilities, but >once we had agreed on the new structure, then several committers could >help in getting the code back in shape. Deciding on the code base >structure "by committee" in the open rather than through a visionary >"dictatorship" is quite a bit of overhead, but also helps build a >common understanding and buy-in of how the project should be. > >For an early project like the Commons RDF incubator, package rename >was done in a day and had minimal impact. Here we didn't do any >structural changes except splitting out a new module. I think keeping >the change lightweight is the best option if possible. > >As Andy pointed out, for a mature project like Jena (with third-party >bindings) you might consider to hold off package rename until the next >major release, which could be years down the line. You can still use >the org.apache.* packages for new stuff, and if you have a clear >api/impl split, also gradually move impl modules under org.apache. > > > > >On 10 August 2015 at 02:28, Roman Shaposhnik <ro...@shaposhnik.org> wrote: >> Thank you all for the feedback. This is super helpful! >> >> One question that I still have is this: do we have a bias >> for suggesting package rename or any package name >> can remain in place? >> >> Thanks, >> Roman. >> >> On Sat, Aug 8, 2015 at 2:25 AM, Andy Seaborne <a...@apache.org> wrote: >>> Hi, >>> >>> Jena graduated 2012 with old namespaces under com.hp.hpl.jena, and some >>> under org.openjena, with an intention to change at the first major >>>release >>> update. As new packages came along, they went into org.apache.jena >>>but the >>> user facing packages remained where they were. >>> >>> We released Jena 3.0.0 last month, so 3 years. That major release was >>> coupled to another incompatible change (RDF 1.1 semantics) so 3.x >>> wasn't just to do the packages, package renaming waited until a >>>convenient >>> point. >>> >>> Our users have data with (RDF) namespaces under old names - we are not >>> planning on changing that at all. (A general issue for all linked >>>data.) >>> >>> I don't see it as an issue for graduation if the project has >>>considered the >>> matter. >>> >>> Andy >>> >>> >>> On 07/08/15 23:16, Matthew Hayes wrote: >>>> >>>> Hi all, >>>> >>>> Roman Shaposhnik suggested I open a discussion on the following topic: >>>> >>>> For Apache DataFu, all of the Java classes are declared in a datafu.* >>>> namespace. This has been the naming convention since the DataFu >>>>project >>>> started in 2010. Since DataFu became part of the Apache incubation >>>> process, the topic has come up of moving all of the classes into a >>>> org.apache.datafu.* namespace. This was first discussed in January >>>>2014 >>>> (see DATAFU-7) and most recently again in the past couple weeks. The >>>> consensus at the time last year was that it would be a huge pain for >>>>users >>>> and not worth the cost. It would break any script out there currently >>>> using DataFu. Also Jakob Homan and Russell Journey pointed out that >>>>this >>>> is just a convention and not all Apache projects follow it. Since we >>>> would >>>> like DataFu to graduate sometime soon it would be good to clarify >>>>what the >>>> requirements are on package naming conventions before we do a release. >>>> >>>> Thoughts? >>>> >>>> Thanks, >>>> Matt >>>> >>> >>> >>> --------------------------------------------------------------------- >>> 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 >> > > > >-- >Stian Soiland-Reyes >Apache Taverna (incubating), Apache Commons RDF (incubating) >http://orcid.org/0000-0001-9842-9718 > >--------------------------------------------------------------------- >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
