Stick to Semantic Versioning.
The official way of releasing TYPO3 extensions is to the TER, extensions existing solely as Git repositories are NOT properly made available to the community.
- master branch should always target upcoming version of TYPO3
- You should try to keep backward compatibility as for TYPO3 CMS, that is, deprecate API and remove 2 versions (major/minor) later
The branch structure within your project may vary but basically, you should have a branch containing code base compatible or aiming at being compatible with the upcoming version of TYPO3. E.g., during the development of TYPO3 7 LTS (at time of writing version 7.3.0 is about to be released), one of your branches should target 7.99.99.
Rationale: even if you cannot afford investing time (and thus money) for a version of TYPO3 you still don't support (your clients are using TYPO3 6.2 LTS and not any 7.x snapshot version), having a branch eventually targeting 7.x (read: the upcoming version at time of reading) allows users to suggest changes and patches to make it compatible.
When your master branch (and no other branch exists for "dev") is stuck to 6.2 compatibility, you give the wrong signal that your extension is likely to not being actively maintained and developped anymore and that using it is actually a risk because it may prevent the user to upgrade the website when 7 LTS is out.
Public extensions (released to TER) should be developped in a public repository as well. This is obvious if you think about getting bug fixes from your users.
- You should ask for contribution in the form of either pull requests (GitHub) or patch sets sent to Gerrit (TYPO3 Core and basically every 3rd-party extension hosted on git.typo3.org)
- Contributions should be related to tickets in a bug/feature tracker
- Documentation should be written in Sphinx (read more)
How-to properly release
- Ensure every local modification is committed
- Raise version (in
ext_emconf.phpand Documentation, composer, ...) and commit
- Publish the extension to TER (with a meaningful upload comment, ideally together with link to release notes)
- Tag the version (
git tag 1.2.3 && git push --tags)
- Raise version to next target (normally patchset release
1.2.4-dev) and commit