Notas da versão do Android Studio

Este documento contém instruções sobre como criar as notas da versão do Android Studio.

Objetivo

Para criar notas de lançamento detalhadas para commits de um repositório do GitHub.

Instruções

Siga estas instruções em ordem e por completo.

Etapa 1: clonar ou atualizar o repositório

Verifique se há uma pasta "studio-main" nesse projeto. Se não houver, clone o repositório studio-main usando o seguinte comando:

git clone -b studio-main sso://googleplex-android/platform/tools/base studio-main

Se o diretório já existir, atualize-o extraindo o conteúdo do repositório do GitHub.

Informe o status de "studio-main" antes de continuar.

Etapa 2: estudar o repositório

Estude o conteúdo do repositório.

Etapa 3: receber os commits

Receba todos os commits enviados ao repositório studio-main durante o período que eu forneci. Me diga a contagem antes de continuar. Sempre use wc -l para contagem.

  1. Identifique os commits de destino: no git log, extraia o bloco de commit completo para cada commit que contenha a string exata "Relnote: ", em que é o nome do produto que forneci. Se eu não fornecer um nome de produto, basta pesquisar "Relnote".

    Um "bloco de commit" inclui o hash do commit, o autor, a data, a mensagem completa do commit e o diff do código.

  2. Use a ferramenta correta: para filtrar commits por período e nome do produto, use o seguinte comando:

    git log --after="" --before="" --grep="Relnote: "

    em que e são o período que eu informei, e é o nome do produto que eu informei.

    Se um nome de produto não for fornecido, use o seguinte comando:

    git log --after="" --before="" --grep="Relnote"

  3. Confirme a contagem: mostre o total, os hashes e os títulos de todos os commits que você identificou. Vou dar uma confirmação para continuar.

Etapa 4: gerar notas de lançamento detalhadas

  1. Analise cada commit: para cada um dos commits identificados na etapa anterior, faça uma análise detalhada, que inclui:

    • Ler a mensagem de commit completa.
    • Examinar a diferença de código (git show ) para entender a mudança.
    • Acompanhar os bugs vinculados (por exemplo, Bug: 12345678) para coletar mais contexto.

    Confirme comigo antes de continuar.

  2. Analise todos os documentos relacionados na pasta "docs" para encontrar informações sobre os commits. Use essas informações para criar uma nota de versão com muito conteúdo.

    Antes de continuar, informe quais commits têm informações relacionadas na pasta "docs".

  3. Receba todos os bugs referenciados nos commits. Use as informações no bug para criar a nota de lançamento do commit.

  4. Escreva a nota da versão: para cada commit, escreva uma nota da versão que inclua:

    • Referência de commit: preceda cada nota de versão com um comentário em Markdown que contenha o hash do commit de origem, assim: .

    • Um título claro: um resumo conciso e em maiúsculas da mudança.

    • Uma explicação detalhada: um parágrafo explicando sobre o que é a mudança.

    • Pontos principais sobre a mudança nesta ordem:

      a. Por quê: o que mudou e por que mudou b. Impacto: o impacto nos desenvolvedores de apps c. Migração: o caminho de migração (se houver)

    • Exemplos de código "antes" e "depois": se o commit envolver uma mudança de código voltada ao usuário (por exemplo, mudanças de DSL em arquivos .gradle ou modificações de API), forneça snippets de código claros e concisos demonstrando a mudança.

    Siga o estilo das notas da versão em https://developer.android.com/studio/releases.

Etapa 5: gravar as notas da versão em um arquivo Markdown

  1. Crie um arquivo Markdown chamado release-notes-AAAA-MM-DDTHH:MM.md na raiz do projeto, em que--no formato ISO 8601--AAAA-MM-DD (ano-mês-dia) é a data atual, T é um separador, e HH:MM (horas:minutos no formato de 24 horas) é a hora atual.
  2. Escreva uma introdução que explique o objetivo das notas da versão.
  3. Escreva um resumo das notas da versão.
  4. Escreva as notas da versão completas e formatadas.

Etapa 6: criar um commit

Crie um commit do Fig para o arquivo de notas da versão. Não inclua um ID de bug.

Etapa 7: criar uma lista de mudanças

Crie uma CL da confirmação.