-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathReleaseNotes
56 lines (43 loc) · 2.32 KB
/
ReleaseNotes
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
0.5
---
Two new plugins: git-sync, for synchronized git usage, and issue-claiming,
which allows you to claim issues for yourself. See PLUGINS.txt for details.
0.4
---
- Command-line completion scripts are now included for bash and zsh. To
activate, source the relevant file in $GEMDIR/ditz-0.4/contrib/completion/.
- Hooks can now be set on a per-project basis. Make a .ditz/hooks directory in
your project root and place them there. These will be loaded after any
hooks in ~/.ditz/hooks, so they can override or simply supplement.
- The plugin system is done. There's currently one plugin, for git integration.
To enable it, add the line "- git" in a .ditz-plugins file in your project
root. The git plugin currently has the following features:
- Issues can have a git branch assigned to them with "ditz set-branch".
- Git commit messages can have a Ditz-issue: header auto-filled if you
commit with "ditz commit <issue>" (i.e. instead of git commit).
- In both HTML and screen output, commits from the assigned branch, and
commits with the corresponding Ditz-issue: header in the log message,
will be listed for each issue.
Note that the plugin system is independent of the hook system. In order
to auto-add ditz files to the git index upon modification, you must set
up hooks. Example hooks for git are at:
http://hackety.org/2008/06/26/gitHooksForDitz.html
Also note that as soon as a feature branch is merged back into master, ditz
loses the ability to distinguish its commits. So the Ditz-issue: approach
is probably better if you want a long-term record.
0.3
---
Ditz now works from project subdirectories, and you can have a .ditz-config in
the project root for project-specific configuration. (This is not merged with
the global config, so this file overrides everything in ~/.ditz-config.)
You can specify an :issue_dir key in this file, which can be a relative path to
the directory containing project.yaml. So if you want to rename that directory,
or keep it somewhere else, now you can.
There's also a new hook system for plugging in your own code. Run ditz -l to
see a list of available hooks.
0.2
---
In ditz 0.2, we store issues per file. This avoids many unnecessary conflicts
that occur in the single-file case.
To upgrade your bugs.yaml to a bugs/ directory, you must run
ditz-convert-from-monolith.