Sounds good to me. We should probably find a home for this information. Somewhere in our contributor guide, perhaps? On 2/14/19 10:00 AM, Colleen Murphy wrote:
On Thu, Feb 14, 2019, at 4:50 PM, Morgan Fainberg wrote:
I think a `git blame` or history of the deprecated release note is nice, it centralizes out tracking of removed/deprecated items to the git log itself rather than some external tracker that may or may not be available forever. This way as long as the git repo is maintained, our tracking for a given release is also tracked.
Specs and bugs are nice, but the deprecated bug # for a given release is fairly opaque. Other bugs might have more context in the bug, but if it's just a list of commits, I don't see a huge win. I'm also +1 on just keeping it in the release notes.
On Thu, Feb 14, 2019, 10:28 Lance Bragstad <lbragstad@gmail.com wrote:
On Thu, Feb 14, 2019, 06:07 Colleen Murphy <colleen@gazlene.net wrote:
What should we do about tracking "deprecated-as-of-*" and "removed-as-of-*" work? I never liked how this was done with blueprints but I'm not sure how we would do it with bugs. One tracking bug for all deprecated things in a cycle? One bug for each? A Trello/Storyboard board or etherpad? Do we even need to track it with an external tool - perhaps we can just keep a running list in a release note that we add to over the cycle?
I agree. The solution that is jumping out at me is to track one bug for deprecated things and one for removed things per release, so similar to what we do now with blueprints. We would have to make sure we tag commits properly, so they are all tracked in the bug report. Creating a bug for everything that is deprecated or removed would be nice for capturing specific details, but it also feels like it will introduce more churn to the process.
I guess I'm assuming there are users that like to read every commit that has deprecated something or removed something in a release. If we don't need to operate under that assumption, then a release note would do just fine and I'm all for simplifying the process.
I think the reason we have release notes is so people *don't* have to read every commit.
Colleen