github.com/jlmucb/cloudproxy@v0.0.0-20170830161738-b5aa0b619bc4/src/third_party/gflags/NEWS (about)

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