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)
- Ensure every local modification is committed
- Raise version (in
ext_emconf.php
and 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
Oh the subject of Gizzle - I was told by the server team a while ago that they'd like to implement a self-hosted version of exactly the project Kay mentioned, which I assume would then be integrated with TER so that adding a GitHub repository URL and some sort of token would enable automatic TER releases from GitHub.
The only thing that would happen to the release process described above, is the 3rd step which is no longer necessary. It would simply be grabbed from the tagged Git release after the 4th step. Any non-tag push is just ignored.