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