commit/todo: 2 new changesets
- From: commits-noreply@xxxxxxxxxxxxx
- To: nvda-addons-commits@xxxxxxxxxxxxx
- Date: Sat, 26 Oct 2013 08:58:23 -0000
2 new commits in todo:
https://bitbucket.org/nvdaaddonteam/todo/commits/3b276618d6a4/
Changeset: 3b276618d6a4
Branch: None
User: josephsl
Date: 2013-10-26 10:57:48
Summary: Todo: moved script category discussion to history list.
Affected #: 1 file
diff --git a/todo.txt b/todo.txt
index 2c47306..41dcd5f 100644
--- a/todo.txt
+++ b/todo.txt
@@ -9,10 +9,9 @@ bitNVDA=http://bitbucket.org/nvdaaddonteam
# To Discuss #
-* Script category: should we use categories from NVDA core, define our own or
use add-on name?
-
# Historical/notes #
+* Script category: use NVDA core categories if an add-on enhances the
functionality of NVDA such as adding shortcuts to preferences dialogs; use
add-on name if the add-on adds misc features such as system information.
* document where the prefered path of addon config files should be saved in
guidelines document.
The new path allows for addons to be used while running temp copy of nvda or
something like that.
* Let commit emails go to a commit list, rather than to the nvda-addons
discussion mailing list.
https://bitbucket.org/nvdaaddonteam/todo/commits/5668a73dae92/
Changeset: 5668a73dae92
Branch: master
User: josephsl
Date: 2013-10-26 10:58:11
Summary: Merge branch 'master' of https://bitbucket.org/nvdaaddonteam/todo
Affected #: 1 file
diff --git a/guideLines.txt b/guideLines.txt
index d2bec19..1f7ccb7 100644
--- a/guideLines.txt
+++ b/guideLines.txt
@@ -18,12 +18,12 @@ Dashes in names are currently not supported by the
automated system.
1. Use major dot minor revision, example: 1.0, 1.1 etc.
2. When new functionality is added, update major revision, i.e. 2.0, 3.0.
-3. When making a release that has only translation updates, update the minor
revision, 3.1, 3.2 etc, add the new languages to the readme.md.
+3. When making a release that has only translation updates, update the minor
revision, 3.1, 3.2 etc. Making sure that the new languages are mensioned in a
commit message. There is no need to add the new languages to the readme.md.
4. git tag the release, note special git push for tags.
## Release process ##
-1. After releasing an add-on version, if you know that you will be making
changes to both old and new major versions, use a separate maintenance branch
for the old version (e.g. 1.x, 2.x, etc.) with the maintenance release commited
from the old version branch. Then merge the old changes to the new major
version.
+1. After releasing an add-on version, if you know that you will be making
changes to both old and new major versions, use a separate maintenance branch
for the old version (e.g. 1.x, 2.x, etc.) with the maintenance release
committed from the old version branch. Then merge the old changes to the new
major version.
2. After making a stable release (and generating the add-on installation
package), update the version to indicate that its under development for the
next version, i.e. 3.1-dev. Note this means that the version number should only
be 3.0 for a few minutes, and should be changed to 3.1-dev to indicate new
development. The version number can be changed from 3.1-dev to 4.0-dev if/when
new features are added.
3. A stable release (such as 1.0, 2.0, 2.1, etc.) should be posted as a stable
add-on, provided that there are no critical bugs reported within the past two
weeks after the last commit. An add-on (or a version of an add-on) under active
development and for which regular commits are made should be listed as a
development add-on for testing by users.
4. Stable releases should be made no closer than 2 weeks apart, to allow
translators to do their work, unless fixing a chritical/showstopper bug.
@@ -48,5 +48,5 @@ Dashes in names are currently not supported by the automated
system.
1. If you are adding new keyboard commands as part of your add-on, be sure to
consult NVDA Command Quick Reference and other community supported add-on
commands before assigning a new command.
2. For NvDA 2013.3 or later: If you wish to categorize your keyboard bindings
(for easier identification so the user can change it), either assign the same
category as NVDA script categories (if your add-on enhances some parts of NVDA
such as adding a shortcut to a preferences dialog) or create new categories if
needed (if the add-on provides other features such as support for advanced
features of a program).
3. Please provide a readme.md file listing changes between versions, shortcut
keys (if any) and usage notes and other information, see one of the other git
repos for examples.
-4. Files addon/doc/*/readme.md should not be translated by hand and committed
to the repositry, but should be generated and committed from the translation
system.
+4. Files addon/doc/*/readme.md should not be translated by hand and committed
to the repository, but should be generated and committed from the translation
system.
5. If you translate an addon to your language and commit to git, please inform
your nvda translation maintainer for your language so that work is not
duplicated, in any case it is better to keep translations on the translation
system.
Repository URL: https://bitbucket.org/nvdaaddonteam/todo/
--
This is a commit notification from bitbucket.org. You are receiving
this because you have the service enabled, addressing the recipient of
this email.
Other related posts:
