DART needs a new name

[karenliu]

Dear DART community,

It's been exciting to see how much DART grow in the past two years thanks to our devoted users and contributors. As DART becomes increasingly popular, we started to receive some requests of name change from other software owners who use similar names. The most similar one is the DARTS rigid body simulator from JPL. To avoid potential confusion down the road, we have made a painful but necessary decision to change the name effective on the next major version release. @jslee02, @mxgrey, and myself have come up with a short list of candidates which can be found here. We would love to hear your thoughts before we make the final decision. Thank you for your support and interest in DART.

Karen Liu

[mxgrey]

Here's a larger version of the link to the poll, just to make it more clear.

[mklingen]

TIL DART is not DARTS from JPL!

[mkoval]

Was there any conclusion from the poll? How do you plan to roll out the name change?

I recently got burned by this because DARTConfig.cmake conflicts with the DartConfig.cmake file that ships with recent versions of CMake if you are using a case-insensitive filesystem (the default on OS X).

:sweat:

[karenliu]

Since there is no clear winner from the first poll, we came up with a few other names and will do a second poll on November 2. If you have any suggestions, please email @jslee02, @mxgrey, or @ckarenliu.

[mklingen]

I have a pretty easy one: DRAT: Dynamic Robotics and Animation Toolkit.

[scpeters]

I still like rtql8, but I'll wait for the new poll.

[mklingen]

rtql8 ends in a number (which is confusing), is longer than dart (by one letter or 3 syllables), is harder to type, and harder to figure out what it says through phonetics. (Rahtwikel-8? Are-tee-kew-el-8?) but at least it has the advantage of being unique!

[scpeters]

@mklingen those are excellent points. As someone involved in packaging, I especially appreciate the issues with having a number in the package name. Also, the lower-case l could look like the number one, especially when next to the 8.

I think my main issue with the other options in the survey is that it would be hard to get good search result placement, since they are such common words.

[psigen]

Well, we have until next week to get some new names, let's get brainstorming!

[jslee02]

1st Poll Result

Thanks to everyone for participating in the poll. We have received a number of responses from DART community. The following is a summary of the poll result.

Name	Percent	Std Dev	Reason to Liked	Reason to Disliked
KinD	28.0%	0.89	easy to say and cute name	not unique, similar to KDL, too narrow to represent the whole functionality
akin	26.1%	0.96	easy to say	not unique ("akino" suggested), sounds like "aching"
RTQL8	24.8%	1.51	unique, clever, creative name, and the former name of DART	complex to say, a leet-speak name, and followed by number 8
ROSE	21.1%	1.16	includes "robotics"	includes "robotics" (too general) and similar to ROS

2nd Poll

Also, as we promised earlier, we do a second poll as there is no clear winner from the first poll. Here is the link to the 2nd poll: http://goo.gl/forms/dUiVAy8KC9

Thank you for the participating in advance!

[karenliu]

After many discussions and two polls, we have decided that the new name for DART is …… RTQL8!

The top 5 names ranked by the second poll all received similar votes so it was very difficult for us (JS, Grey and myself) to make the final decision. We discussed in length the pros and cons of every candidate name and finally settled on RTQL8. The first version of RTQL8 will be identical to DART 6.0 except for the string replacement from “dart” to “rtql8”. We plan to release DART 6.0 and RTQL8 1.0 at the end of December.

Thank you for your comments and your continue support of DART. We hope that the name change will have minimum impact to your projects.

[mkoval]

@cdellin, @psigen, @mklingen, and I feel strongly that RTQL8 is bad choice. We were satisfied with most of the other names in the poll and are even open to the full word "Articulate".

We have three major concerns:

RTQL8 ends in a number. This makes it difficult to refer to a specific version of the package; e.g. "RQTL8 8". It also leads to misleading package names. For example, Debian packages split the runtime library package (libfoo1) from the development package (libfoo-dev) and suggests the naming convention:

Normally, the run-time shared library and its SONAME symlink should be placed in a package named librarynamesoversion, where soversion is the version number in the SONAME of the shared library. Alternatively, if it would be confusing to directly append soversion to libraryname (if, for example, libraryname itself ends in a number), you should use libraryname-soversion instead.

Version 1 of RTQL8 would consist of the Debian packages librtql81 and librtql8-dev, which looks like RQTL8 version 81. If we follow the alternative guidelines, we would end up with librtql8-1 instead. This is slightly better, but still very confusing: it looks like RQTL8 version 8.1. This gets even worse if you look at the name of .deb file: revision 0 of RTQL8 1.1.0 would be named librtql8_1.1.0-0precise.deb.

The only package names in the Debian repository that end in a number that is not a version number are those that refer to an existing standard (e.g. libavc1394, libkrb5, libx264). The situation might be even worse for other package managers - I am not sure if all package managers (e.g. Homebrew, RPM, etc) even allow this.

RTQL8 is difficult to pronounce. The majority of people in our lab didn't realize that RTQL8 was intended to be pronounced as "articulate" without us prompting them. This has potentially major implications for attracting new users, e.g. who hear about RTQL8 in a conference presentation. They will have no idea what to search for without seeing the name of the package in writing or having it explicitly spelled out.

RTQL8 is difficult to spell. This is exacerbated by the fact that RTQL8 is difficult to spell. While it is anecdotal at best, @psigen and I have around a 50% chance of writing "RTQL8" instead of "RQLT8" (as you can see if you carefully read this post).

I hope you reconsider. DART/RTQL8 is a fantastic library and I'd hate to see a trivial naming issue hurt its adoption. Maybe one of the other top five names would be an acceptable choice?

[siddhss5]

I'm very much in agreement with @mkoval's comment above. We spend an inordinate amount of time at our lab discussing algorithm naming, and my own experience has mostly reinforced the importance of a good name. RTQL8 is cute for [some] computer geeks but perplexing for almost everyone else.

[karenliu]

These are all good points. Many people like RTQL8 because it's unique, it's the original name of DART, and the domain name "rtql8.org" is owned by us. Another name that JS, Grey, and I like, or rather nobody hates, was "kido". What do people think about it?

[mxgrey]

I'd also suggest mentioning kado alongside kido as a name that was generally considered acceptable.

[psigen]

Both kado and kido are perfectly reasonable names. libkado and libkido and many similar variants are still available as domain names, and there are no significant projects with these names as far as I can tell (there is a ruby project called kado, but it doesn't dominate search results).

[mkoval]

kado and kido both seem like decent names - I would be fine with either of them. Like @psigen mentioned, they also both seem pretty Google-able.

Thanks for considering our comments! :smile:

[mklingen]

There's also this... http://rtql8.com/

[scpeters]

Are there any updates on a 1.0 release with the new name? @j-rivero mentioned to me that we should submit it soon to the debian new queue if we want it to be included in the LTS version of Ubuntu that will be released in April. If we wait too long we will probably miss that deadline.

[jslee02]

We planned to release KIDO, which is the new name of DART, around mid-February. Would it be soon enough to be included in the LTS version of Ubuntu? Actually, I didn't know that KIDO is going to be included in the Ubuntu main repository.

[j-rivero]

I work in the debian-science group bringing and maintaining some of the open source robotics packages into Debian. This has the good side effect that Ubuntu syncs packages from Debian often. DART is one the next in my list.

Ubuntu will stop syncing packages from Debian two months before the release date. For the next Ubuntu Xenial, the last day to sync packages from Debian is February 18th. New packages usually take sometime to review by Debian developers so we will need at least a month (more or less) to ensure that a new package is on time to get synced for the next Ubuntu version.

I could try to get DART inside debian and after that rename it, but that is not really fun and takes, again, time for reviewing. This is why Steve were asking about the name change.

[jslee02]

If I understood correctly, KIDO 1.0.0 should be ready to be released (at least just for packaging) around January 18 (one month ahead of the last day to sync packages) so that the Debian developers can review it, right?

Once KIDO is ready regarding packaging at January 18, would it be possible to add more features after that? If so, we can change the name first (as current master branch is) and then add features later. That would be more predictable in packaging.

[j-rivero]

If I understood correctly, KIDO 1.0.0 should be ready to be released (at least just for packaging) around January 18 (one month ahead of the last day to sync packages) so that the Debian developers can review it, right?

Although the times are not fixed (there is no maximum time to be waiting for review of new packages), yes, would be nice to get it ready on Jan 18th.

Once KIDO is ready in terms of packaging at January 18, would it be possible to add more features after that?

You can add more features at any time, my point as maintainer would be to package every version you release and the point of Debian/Ubuntu is to select a version when building a new distro (Ubuntu Wily, in this case).

For example: you release KIDO 1.0.0 on Jan 18th, I package it and submit on Jan 20th and Debian accepts it on Feb 10th. In this time you made a KIDO 1.1.0 on Feb 11th. I can package it on Feb 12th and (since the package is already in Debian) the update is automatically accepted. So when Ubuntu finishes the sync from debian on Feb 18th, we will get KIDO 1.1.0 for Ubuntu Wily. If you release KIDO 1.2.0 on March 1st, I will package it for debian but won't be present on Ubuntu Wily.

If so, we can change the name first (as current master branch is) and then add features later. That would be more predictable in packaging.

+1 if this is fine for you.

[jslee02]

Thank you for the clarification!

I created a branch for renaming (without changing features) here and started renaming.

Actually, I have one more question. There will be API breaking in the next release (would be made on Feb 11 in your example scenario). I wonder if it's possible to submit KIDO 0.1.0 (or something less than 1.0.0) on Jan 20 and then submit KIDO 1.0.0 (with API changing) on Feb 11.

[j-rivero]

I wonder it's possible to submit KIDO 0.1.0 (or something less than 1.0.0) on Jan 20 and then submit KIDO 1.0.0 (with API changing) on Feb 11.

It is possible and sounds like the best option to me. The semantic versioning recommendations are that anything prior to 1.0.0 is not consider API stable. So 0.1.0 (meaning the first of non API stable version) or 0.9.0 (if you consider that 1.0.0 is close) can work perfectly.

Thanks!

[jslee02]

Okay, I will follow the procedure as discussed above unless someone has more opinion. Also, 0.9.0 sounds better to me since it's close to 1.0.0. 0.1.0 would make more sense since we have major features that will be merged into 1.0.0 after that.

[mkoval]

It may be simpler to continue KIDO's version numbers where DART's left off. For example, the first release of KIDO would be 7.0. This makes it clear that KIDO is the successor to DART (not visa versa) and avoids ambiguity where the version numbers overlap. For example, it's potentially confusing to say "version 1.0" since it could refer to DART 1.0 or KIDO 1.0.

I don't feel strongly about this - I just wanted to bring the idea up for discussion.

[karenliu]

This is a good point. When NovodeX was renamed to PhysX, they started the version number from 2.3, which was the last stable release of NovodeX.

[jslee02]

Continuing version number sounds reasonable. Now I started to consider to release KIDO 6.0 without DART 6.0. The main reason we planned to release DART 6.0 (and KIDO 7.0 with the only name changed) was to minimize impacts from the name change for the users, but I'm not sure if it's worthwhile when DART 6.0 breaks the API compatibility anyways.

[mxgrey]

I think it's good to release both so that people can easily distinguish API changes from package name changes. It's difficult enough to update your code base when the API breaks, but doing so when the package name also changes would probably be a nightmare. If we release both, then people have the opportunity to deal with API changes first and then deal with package name changes after their API usage is up-to-date.

[jslee02]

That's true. I just worry about the disaster of merging DART 6.0 and KIDO 0.1.0. There would be tons of conflicts.

[mxgrey]

Yeah, I don't think we should merge directly. I think instead we should do a conversion each time. So the branch dart-release-6.0 would be directly converted to kido-release-1.0 and it wouldn't descend from kido-release-0.1 at all.

[jslee02]

Right, that's a good solution! I was about to say that, but you beat me.

So we will have DART 6.0 and KIDO 7.0 at mid-February.

[jslee02]

Also, we should make sure if it's acceptable to submit KIDO 0.1.0 to Debian and then jump to KIDO 7.0.0. If not, we might need to change KIDO 0.1.0 to a version that sufficiently close to 7.0.0.

[psigen]

Is there a mechanism for pre-release versions like 7.0.0-beta?

[jslee02]

@j-rivero Could you shed some light on us?

[mkoval]

@psigen I don't think that is possible because semantic versioning allows breaking changes in any version less than 1.0.0. We could follow @jslee02's suggestion and release 0.1.0 as a placeholder and jump straight to 7.0.0.

That is fine according to semantic versioning, but it may violate a Debian policy. Hopefully @j-rivero can clarify.

[j-rivero]

That is fine according to semantic versioning, but it may violate a Debian policy. Hopefully @j-rivero can clarify.

The debian policy really does not worry about weird versioning practices as far as they are in order. release a 0.1.0 and after that a 7.0.0 in debian is fine, as it just follows upstream (in this case you guys, developers of KIDO) and it is in order (7.0.0 > 1.0.0 so fine).

In summary: if we are going to change the API, release a first KIDO 0.x.y (0.1.0 or 0.6.99 if you want to give a hint about what will come next) and after that KIDO 7.0.0 with the stabe API is ok for both, semantic versioning and debian policies.

Note that in debian a version could be in the form of: 0.1.0, 0.1.0~pre1, 0.1.0~beta1, 0.1.0isDART6.0, or even 3.3.2is3.2.2, etc. https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

[jslee02]

Thanks @j-rivero! KIDO 0.1.0 seems a simple solution satisfying both of semantic versioning and Debian policies as @j-rivero clarified.

[jslee02]

@j-rivero KIDO 0.1.0 is released. I uploaded KIDO 0.1.0 to ppa:dartsim for test, and it was successfully built on wily (I will upload for trusty and vivid soon). Could you help us to submit KIDO 0.1.0 to Debian? Please let me know if there are more steps I can assist.

[j-rivero]

@j-rivero KIDO 0.1.0 is released. I uploaded KIDO 0.1.0 to ppa:dartsim for test, and it was successfully built on wily (I will upload for trusty and vivid soon). Could you help us to submit KIDO 0.1.0 to Debian? Please let me know if there are more steps I can assist.

After some months, I'm back again to work on the debian/ubuntu official packages. Preparing the next Ubuntu Yaketty release. Is there any new release of KIDO planned or I should focus on getting the 0.1.0 version? Thanks!

[j-rivero]

Back to work on updating my maintained Debian packages.

Note that KIDO is part of the official ubuntu/debian packages with the version 0.1.0. Sorry I did not follow the changes and releases in this repo but I see new releases still with the name of DART. Should I try to update the package with the name of KIDO or make a transition from current KIDO to DART?

Thanks!

[jslee02]

We've through long discussion internally but finally decided not to change the name. It would be great if we can transit the ubuntu package name to DART. Please let me know if anything I can help for that!

[scpeters]

I hadn't tested gazebo with dart on macOS in a while, since I've been using Ubuntu mostly, but I tried again today. Note that gazebo uses find_package(DART). That works on Ubuntu but wasn't working for me on macOS because cmake has a FindDart module for dartlang, and my macOS filesystem is not case sensitive. I assume windows would have the same problem. The workaround is to add CONFIG to the find_package call, but it's also relevant to this issue, even if the issue is closed.

[mxgrey]

We may want to consider naming the package DartSim, or something similar, even if we keep the library name the same. For debian would it be "acceptable" to make the package name libdartsim# while keeping the library name libdart#?

Avoiding this kind of ambiguity was one of the motivations behind renaming; it's unfortunate that we couldn't come up with a generally compelling replacement name.

[jslee02]

I agree. I think we just should change the CMake package name to DartSim (or DARTSim). It would be fine not to change the Ubuntu package name since the name confliction doesn't exist on Ubuntu; The Ubuntu package name of DART language is dart.

[mxgrey]

I don't know if this would be a concern, but I wonder if libdart might be seen as too generic of a name by the Debian maintainers, or too similar to dart. If it gets rejected on those grounds, we may want to consider libdartsim. @j-rivero would have a much better idea about this than me.

[j-rivero]

I don't know if this would be a concern, but I wonder if libdart might be seen as too generic of a name by the Debian maintainers, or too similar to dart. If it gets rejected on those grounds, we may want to consider libdartsim. @j-rivero would have a much better idea about this than me.

Note that when we go into Debian we will have one source package, usually corresponding with upstream name. In the case of dart, we can use dart (there is another package called darts, that could cause some problems), dartsim or libdart. From that package source we will generate different packages, in the case of libraries, the policy says that we will find libfooN (N is the SONAME), libfoo-dev, ... This can sound like a conflict with naming the source package libdart but the SONAME at the name makes the difference and we find lot of source packages in Debian with the name of libFOO (example, libavl). Hope that all this makes sense to help you decide.

[scpeters]

@j-rivero in my comment https://github.com/dartsim/dart/issues/479#issuecomment-359595070 I noticed a problem with find_package(DART), so I think we would also want to rename the cmake config file. Would that be ok?

[mxgrey]

I'm somewhat inclined to think that the debian package name should preferably match the cmake package name rather than the library name, because I feel that would make it easier for end-users who presumably would use cmake to build against DART.

In other words, if we want our cmake package name to be DartSim, then the debian package name should maybe be dartsim rather than libdart so that when cmake fails to find "DartSim", the user can find it more easily from their package manager of choice. Ideally, users shouldn't be handling the library name directly anyway, so I think having consistent use of the package name is the most important thing.

That's just my inclination; I don't have a super strong opinion about what the "right" convention is.