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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp