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
