A única razão pela qual o marco 3.3.3 foi marcado como concluído é porque deixar o marco aberto interferiu em nossos relatórios de tickets para 3.4.1. (Esqueci que os fechamentos de marcos são refletidos na linha do tempo.)
De um modo geral, atribuímos tickets para o próximo marco menor se eles estiverem relatando uma regressão imediata. Portanto, uma regressão no 3.2 que surge durante o desenvolvimento do 3.3 teria sido atribuída ao 3.2.2, como aconteceu aqui. Nesse caso, chegamos ao ponto de fechar esses tickets com um commit contra a ramificação 3.2. Às vezes, fazemos isso principalmente por motivos de limpeza e, se houver necessidade de uma liberação, estaremos mais preparados. Mas como nada disparou o lançamento do 3.2.2 (um bug suficientemente crítico ou algo relacionado à segurança), acabamos de fechar o marco. Isso é útil para fins de rastreamento. Poderíamos excluí-lo com a mesma facilidade e redesignar todos os tickets para o 3.3. Nós simplesmente não fizemos neste caso.
Edite, adicionando mais informações: vale a pena notar que sempre nos esforçamos para que os ramos da versão sejam o mais estáveis possível. Portanto, se você estiver executando a ramificação 3.2 e sempre a manter atualizada, poderá estar executando algo "mais estável" que a versão estável da 3.2.1. Esses tipos de correções extras geralmente entram em uma ramificação após o lançamento do ponto final para essa ramificação e, portanto, não são liberados.
Lançamos pacotes formais em raras ocasiões - o 3.0.6 foi lançado ao mesmo tempo que o 3.1.2. Em geral, tentamos manter o segundo ramo mais recente (por exemplo, 3.0) até que o ramo de desenvolvimento atual (por exemplo, 3.2) tenha atingido o status "beta". Não anunciamos a disponibilidade do 3.0.6, mas qualquer pessoa executando o ramo 3.0 poderia pelo menos ter atualizado essas correções por meio de canais oficiais.
