Open Stack

On 2013-06-03 10:01:03 -0700 (-0700), Lloyd Dewolf wrote:
> I appreciate that it often isn't appropriate, but in this case it
> might have been beneficial to include python-keystoneclient
> version 0.2.4 where this is first resolved.

What's the better way to do that, do you think? Delay the
announcement until a new release is tagged, guess what the release
will be numbered (possibly doable with the assistance of the
developers as long as they don't change their minds), or follow up
to the announcement after the fact? I opted for expediency and
accuracy, indicating the date and commit hash stating "will appear
in the next release," but am happy to entertain alternative
approaches there.

I agree it's less than ideal for end users reading the announcement
and trying to decide whether they're running a new enough version of
the client to have access to that feature, though I guess the
manpage or --help output is the first place I would look as a user
if it came into question. Also, with many users running
stable-distribution-packaged clients with fixes backported, upstream
version numbers can be fairly irrelevant to those users in the short
term as they may have the fix in a client reporting to be running an
older version.
-- 
Jeremy Stanley