README.md

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