When you develop Symfony 2 applications you often reuse code, since - if you have worked decoupled enough - bundles are really easy to move from one application to another. You can do it the quick and dirty way, copying files from one repository to another, ore you can do it just right. The bare minimum to keep it clean is to semantically expose your services and parameters and move the bundle to an indipendent repository, that will be common among the projects. All you need to do then is addiing the custom repository to the composer.json files of all the projects you are going to use the bundle in, and addiing some configuration in config.yml.
You are going to distribute your software, people are going to use it, hopefully, and let some of their project depend on it: you should be a meticulous mantainer.
You should be meticulous in properly branching your bundle, in order to mantain and differentiate compatibility with your dependencies. If, for example, a new version of one of your dependencies introduces a BC break with a new major release, you should create a new branch in order to follow it, not forcing your users to upgrade to the new dependency. Let's make a quick example: SpaghettiIoApiBundle 2.0.x is released introducing a major BC break; your bundle is at 1.0.x version and has a dependency on its previous version, 1.8.x; you should introduce a new major branch (2.0.x - but a new minor will be okay too) in your repository to highlight this change and start supporting both branches (at least until it makes sense).
If you don't want to support both branches (and want to remove support for the old dependencies) you should at least make a tag, if not already available, just before introducing the bc break. As a rule of thumb, your dev-master branch, that usually is an alias of the latest major branch, should always be working - green tests :-) - with the latest development branches of all of its dependencies; the dependency version constraints in your composer.json should be weak enough to let the oldest tested working version be installable. Fore example: your 2.0.x branch depends on symfony/yaml; you know that it won't work with the 2.0.x branch, but you know it works with the 2.5.x one; you can start testing it with previous versions of the dependencies and fix the version constraint accordingly; in this case, you'll realize that symfony/yaml will work with your project from its 2.1 version and you will finally set the version constraint in your composer.json to "~2.1".
Whether you decide or not to mantain more than one branch, if your bundle is active enough you should start releasing new tags every time your software reaches significant stable states. Each tag should inherit its branch major and minor versions and get the patch version incremented by one from the previous. If no branch is available other than dev-master, well, tags should probably look like 0.x.x. Take a look at semver.org for a complete reference.
An important step to take in order to make your bundle known to the world is submitting it to packagist.org to make it installable through composer. Package submission is quite easy: you subscribe and once you have a composer.json file with a description of the project and its dependencies you just need to give packagist the repository URL and you are done.
Last but not least, you have to care about coding standards, about code quality (three random buzzwords: DRY, SOLID, IoC), and you should mantain an updated test suite.