{"action":"created","issue":{"url":"https://api.github.com/repos/dartsim/dart/issues/382","labels_url":"https://api.github.com/repos/dartsim/dart/issues/382/labels{/name}","comments_url":"https://api.github.com/repos/dartsim/dart/issues/382/comments","events_url":"https://api.github.com/repos/dartsim/dart/issues/382/events","html_url":"https://github.com/dartsim/dart/issues/382","id":73084522,"number":382,"title":"Remove public constructors for release 5.0?","user":{"login":"mxgrey","id":1307217,"avatar_url":"https://avatars.githubusercontent.com/u/1307217?v=3","gravatar_id":"","url":"https://api.github.com/users/mxgrey","html_url":"https://github.com/mxgrey","followers_url":"https://api.github.com/users/mxgrey/followers","following_url":"https://api.github.com/users/mxgrey/following{/other_user}","gists_url":"https://api.github.com/users/mxgrey/gists{/gist_id}","starred_url":"https://api.github.com/users/mxgrey/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mxgrey/subscriptions","organizations_url":"https://api.github.com/users/mxgrey/orgs","repos_url":"https://api.github.com/users/mxgrey/repos","events_url":"https://api.github.com/users/mxgrey/events{/privacy}","received_events_url":"https://api.github.com/users/mxgrey/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-05-04T17:57:28Z","updated_at":"2015-05-05T16:50:52Z","closed_at":null,"body":"The life cycle for deprecation has been discussed in the past, and the general idea is things should be marked as deprecated for a while before they're completely removed.\r\n\r\nHowever, for release 5.0, we want Skeletons to be managed strictly by shared_ptrs, which also means that Skeletons need to have knowledge of the shared_ptr that is managing them, so they can pass that shared_ptr to their BodyNodes. We want BodyNodes to be aware of the shared_ptr of the Skeleton that owns them so that users can obtain the shared_ptr of a Skeleton from its BodyNode.\r\n\r\nTo facilitate this, we want to create a static function called ``Skeleton::create()`` which will pass back a shared_ptr<Skeleton> where the Skeleton knows the value of its own shared_ptr. This means that constructing a Skeleton using its usual public constructor would be bad, because then the Skeleton would not have knowledge of its own shared_ptr, so the BodyNodes won't have the shared_ptr either.\r\n\r\nAltogether, this means that keeping the public constructor for Skeleton would be harmful.\r\n\r\nTaking this a step further, I wonder if we should keep the public constructors for BodyNode or Joint available at all. We could allow them to be marked as deprecated for a while before removing them entirely, but I'm worried that might be too gentle. As long as we're suddenly breaking the API for Skeleton, it might not matter much if we break the API for BodyNodes and Joints as well."},"comment":{"url":"https://api.github.com/repos/dartsim/dart/issues/comments/99138523","html_url":"https://github.com/dartsim/dart/issues/382#issuecomment-99138523","issue_url":"https://api.github.com/repos/dartsim/dart/issues/382","id":99138523,"user":{"login":"jslee02","id":4038467,"avatar_url":"https://avatars.githubusercontent.com/u/4038467?v=3","gravatar_id":"","url":"https://api.github.com/users/jslee02","html_url":"https://github.com/jslee02","followers_url":"https://api.github.com/users/jslee02/followers","following_url":"https://api.github.com/users/jslee02/following{/other_user}","gists_url":"https://api.github.com/users/jslee02/gists{/gist_id}","starred_url":"https://api.github.com/users/jslee02/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jslee02/subscriptions","organizations_url":"https://api.github.com/users/jslee02/orgs","repos_url":"https://api.github.com/users/jslee02/repos","events_url":"https://api.github.com/users/jslee02/events{/privacy}","received_events_url":"https://api.github.com/users/jslee02/received_events","type":"User","site_admin":false},"created_at":"2015-05-05T16:50:52Z","updated_at":"2015-05-05T16:50:52Z","body":"Yes, we have discussed. Basically, we try to follow [Semantic Versioning](http://semver.org/), and it's recommends on deprecated API is:\r\n> Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.\r\n\r\nSo it would be good to release dart 4.4 with deprecated API then dart 5.0 without them if it's possible. How do you think?\r\n"}}