The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)
Nemo/Development/Releasing
| Line 8: | Line 8: | ||
When you make a release, you need to make a git tag: | When you make a release, you need to make a git tag: | ||
| − | git tag | + | git tag MAJOR.MINOR.PATCH |
and push the tag. If you don't have access to make a release, and you need one, ask someone else (generally the maintainer of that package) to do it for you. | and push the tag. If you don't have access to make a release, and you need one, ask someone else (generally the maintainer of that package) to do it for you. | ||
Latest revision as of 10:06, 5 April 2013
Contents |
[edit] Release information
Software we maintain should release software based on major.minor.revision version numbers.
When to increment those is fairly subjective, I tend to bump patch releases very often (even a few times a day - release often is perfectly fine), minor release bumping is more appropriate for when you realise that some milestone (feature/stability/?) has been realised. Major version bumping is even more rare, it's primarily there to indicate compatibility breaks etc, but use it as you want - we have no firm policy on the meaning of the individual numbers, basically.
[edit] Releasing
When you make a release, you need to make a git tag:
git tag MAJOR.MINOR.PATCH
and push the tag. If you don't have access to make a release, and you need one, ask someone else (generally the maintainer of that package) to do it for you.
After that, locate the package in OBS, branch it (osc branch), update the tarball (git archive, osc add), update the yaml (and run specify). You should then run a local build and make sure that everything installs and works OK, osc commit, wait for it to build OK on all architectures in your home: branch, then osc submitrequest to where the package belongs.
[edit] When to release
Generally speaking, release as often as you like. The more often the better. If we someday have automated QA, it will make finding regressions a lot easier if there's small changes in many releases. Please do make sure your changes are tested.
[edit] When to patch packages
Frequently, new developers to Nemo put patches on top of packages that we maintain when fixing bugs. This should be discouraged; git should be the canonical resource for all development, and patches should go through code review on github before being pushed to OBS. For very trivial fixes noted just after a release, a patch to OBS is acceptable, but see above: releasing often isn't that hard, and you should probably do that instead.
