Update Google libraries
[blender.git] / extern / gflags / NEWS.txt
1 === 30 March 2014 ===
2
3 I've just released gflags 2.1.1.
4
5 This release fixes a few bugs in the configuration of gflags_declare.h
6 and adds a separate GFLAGS_INCLUDE_DIR CMake variable to the build configuration.
7 Setting GFLAGS_NAMESPACE to "google" no longer changes also the include
8 path of the public header files. This allows the use of the library with
9 other Google projects such as glog which still use the deprecated "google"
10 namespace for the gflags library, but include it as "gflags/gflags.h".
11
12 === 20 March 2014 ===
13
14 I've just released gflags 2.1.
15
16 The major changes are the use of CMake for the build configuration instead
17 of the autotools and packaging support through CPack. The default namespace
18 of all C++ symbols is now "gflags" instead of "google". This can be
19 configured via the GFLAGS_NAMESPACE variable.
20
21 This release compiles with all major compilers without warnings and passed
22 the unit tests on  Ubuntu 12.04, Windows 7 (Visual Studio 2008 and 2010,
23 Cygwin, MinGW), and Mac OS X (Xcode 5.1).
24
25 The SVN repository on Google Code is now frozen and replaced by a Git
26 repository such that it can be used as Git submodule by projects. The main
27 hosting of this project remains at Google Code. Thanks to the distributed
28 character of Git, I can push (and pull) changes from both GitHub and Google Code
29 in order to keep the two public repositories in sync.
30 When fixing an issue for a pull request through either of these hosting
31 platforms, please reference the issue number as 
32 [https://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control described here].
33 For the further development, I am following the
34 [http://nvie.com/posts/a-successful-git-branching-model/ Git branching model]
35 with feature branch names prefixed by "feature/" and bugfix branch names
36 prefixed by "bugfix/", respectively.
37
38 Binary and source [https://github.com/schuhschuh/gflags/releases packages] are available on GitHub.
39
40
41 === 14 January 2013 ===
42
43 The migration of the build system to CMake is almost complete.
44 What remains to be done is rewriting the tests in Python such they can be
45 executed on non-Unix platforms and splitting them up into separate CTest tests.
46 Though merging these changes into the master branch yet remains to be done,
47 it is recommended to already start using the
48 [https://github.com/schuhschuh/gflags/tree/cmake-migration cmake-migration] branch.
49
50
51 === 20 April 2013 ===
52
53 More than a year has past since I (Andreas) took over the maintenance for
54 `gflags`. Only few minor changes have been made since then, much to my regret.
55 To get more involved and stimulate participation in the further
56 development of the library, I moved the project source code today to
57 [https://github.com/schuhschuh/gflags GitHub].
58 I believe that the strengths of [http://git-scm.com/ Git] will allow for better community collaboration
59 as well as ease the integration of changes made by others. I encourage everyone
60 who would like to contribute to send me pull requests.
61 Git's lightweight feature branches will also provide the right tool for more
62 radical changes which should only be merged back into the master branch
63 after these are complete and implement the desired behavior.
64
65 The SVN repository remains accessible at Google Code and I will keep the
66 master branch of the Git repository hosted at GitHub and the trunk of the
67 Subversion repository synchronized. Initially, I was going to simply switch the
68 Google Code project to Git, but in this case the SVN repository would be
69 frozen and force everyone who would like the latest development changes to
70 use Git as well. Therefore I decided to host the public Git repository at GitHub
71 instead.
72
73 Please continue to report any issues with gflags on Google Code. The GitHub project will
74 only be used to host the Git repository.
75
76 One major change of the project structure I have in mind for the next weeks
77 is the migration from autotools to [http://www.cmake.org/ CMake].
78 Check out the (unstable!)
79 [https://github.com/schuhschuh/gflags/tree/cmake-migration cmake-migration]
80 branch on GitHub for details.
81
82
83 === 25 January 2012 ===
84
85 I've just released gflags 2.0.
86
87 The `google-gflags` project has been renamed to `gflags`.  I
88 (csilvers) am stepping down as maintainer, to be replaced by Andreas
89 Schuh.  Welcome to the team, Andreas!  I've seen the energy you have
90 around gflags and the ideas you have for the project going forward,
91 and look forward to having you on the team.
92
93 I bumped the major version number up to 2 to reflect the new community
94 ownership of the project.  All the
95 [http://gflags.googlecode.com/svn/tags/gflags-2.0/ChangeLog changes]
96 are related to the renaming.  There are no functional changes from
97 gflags 1.7.  In particular, I've kept the code in the namespace
98 `google`, though in a future version it should be renamed to `gflags`.
99 I've also kept the `/usr/local/include/google/` subdirectory as
100 synonym of `/usr/local/include/gflags/`, though the former name has
101 been obsolete for some time now.
102
103
104 === 18 January 2011 ===
105
106 The `google-gflags` Google Code page has been renamed to
107 `gflags`, in preparation for the project being renamed to
108 `gflags`.  In the coming weeks, I'll be stepping down as
109 maintainer for the gflags project, and as part of that Google is
110 relinquishing ownership of the project; it will now be entirely
111 community run.  The name change reflects that shift.
112
113
114 === 20 December 2011 ===
115
116 I've just released gflags 1.7.  This is a minor release; the major
117 change is that `CommandLineFlagInfo` now exports the address in memory
118 where the flag is located.  There has also been a bugfix involving
119 very long --help strings, and some other minor
120 [http://code.google.com/p/google-gflags/source/browse/tags/gflags-1.7/ChangeLog changes].
121
122 === 29 July 2011 ===
123
124 I've just released gflags 1.6.  The major new feature in this release
125 is support for setting version info, so that --version does something
126 useful.
127
128 One minor change has required bumping the library number:
129 `ReparseCommandlineFlags` now returns `void` instead of `int` (the int
130 return value was always meaningless).  Though I doubt anyone ever used
131 this (meaningless) return value, technically it's a change to the ABI
132 that requires a version bump.  A bit sad.
133
134 There's also a procedural change with this release: I've changed the
135 internal tools used to integrate Google-supplied patches for gflags
136 into the opensource release.  These new tools should result in more
137 frequent updates with better change descriptions.  They will also
138 result in future `ChangeLog` entries being much more verbose (for better
139 or for worse).
140
141 See the
142 [http://code.google.com/p/google-gflags/source/browse/tags/gflags-1.6/ChangeLog ChangeLog]
143 for a full list of changes for this release.
144
145 === 24 January 2011 ===
146
147 I've just released gflags 1.5.  This release has only minor changes
148 from 1.4, including some slightly better reporting in --help, and
149 an new memory-cleanup function that can help when running gflags-using
150 libraries under valgrind.  The major change is to fix up the macros
151 (`DEFINE_bool` and the like) to work more reliably inside namespaces.
152
153 If you have not had a problem with these macros, and don't need any of
154 the other changes described, there is no need to upgrade.  See the
155 [http://code.google.com/p/google-gflags/source/browse/tags/gflags-1.5/ChangeLog ChangeLog]
156 for a full list of changes for this release.
157
158 === 11 October 2010 ===
159
160 I've just released gflags 1.4.  This release has only minor changes
161 from 1.3, including some documentation tweaks and some work to make
162 the library smaller.  If 1.3 is working well for you, there's no
163 particular reason to upgrade.
164
165 === 4 January 2010 ===
166
167 I've just released gflags 1.3.  gflags now compiles under MSVC, and
168 all tests pass.  I *really* never thought non-unix-y Windows folks
169 would want gflags, but at least some of them do.
170
171 The major news, though, is that I've separated out the python package
172 into its own library, [http://code.google.com/p/python-gflags python-gflags].
173 If you're interested in the Python version of gflags, that's the place to
174 get it now.
175
176 === 10 September 2009 ==
177
178 I've just released gflags 1.2.  The major change from gflags 1.1 is it
179 now compiles under MinGW (as well as cygwin), and all tests pass.  I
180 never thought Windows folks would want unix-style command-line flags,
181 since they're so different from the Windows style, but I guess I was
182 wrong!
183
184 The other changes are minor, such as support for --htmlxml in the
185 python version of gflags.
186
187 === 15 April 2009 ===
188
189 I've just released gflags 1.1.  It has only minor changes fdrom gflags
190 1.0 (see the
191 [http://code.google.com/p/google-gflags/source/browse/tags/gflags-1.1/ChangeLog ChangeLog]
192 for details).  The major change is that I moved to a new
193 system for creating .deb and .rpm files.  This allows me to create
194 x86_64 deb and rpm files.
195
196 In the process of moving to this new system, I noticed an
197 inconsistency: the tar.gz and .rpm files created libraries named
198 libgflags.so, but the deb file created libgoogle-gflags.so.  I have
199 fixed the deb file to create libraries like the others.  I'm no expert
200 in debian packaging, but I believe this has caused the package name to
201 change as well.  Please let me know (at
202 [mailto:google-gflags@googlegroups.com
203 google-gflags@googlegroups.com]) if this causes problems for you --
204 especially if you know of a fix!  I would be happy to change the deb
205 packages to add symlinks from the old library name to the new
206 (libgoogle-gflags.so -> libgflags.so), but that is beyond my knowledge
207 of how to make .debs.
208
209 If you've tried to install a .rpm or .deb and it doesn't work for you,
210 let me know.  I'm excited to finally have 64-bit package files, but
211 there may still be some wrinkles in the new system to iron out.
212
213 === 1 October 2008 ===
214
215 gflags 1.0rc2 was out for a few weeks without any issues, so gflags
216 1.0 is now released.  This is much like gflags 0.9.  The major change
217 is that the .h files have been moved from `/usr/include/google` to
218 `/usr/include/gflags`.  While I have backwards-compatibility
219 forwarding headeds in place, please rewrite existing code to say
220 {{{
221    #include <gflags/gflags.h>
222 }}}
223 instead of
224 {{{
225    #include <google/gflags.h>
226 }}}
227
228 I've kept the default namespace to google.  You can still change with
229 with the appropriate flag to the configure script (`./configure
230 --help` to see the flags).  If you have feedback as to whether the
231 default namespace should change to gflags, which would be a
232 non-backwards-compatible change, send mail to
233 `google-gflags@googlegroups.com`!
234
235 Version 1.0 also has some neat new features, like support for bash
236 commandline-completion of help flags.  See the
237 [http://code.google.com/p/google-gflags/source/browse/tags/gflags-1.0rc2/ChangeLog
238 ChangeLog] for more details.
239
240 If I don't hear any bad news for a few weeks, I'll release 1.0-final.