Ciclo de Versões do Software

A partir de agora a PC Sistemas adotará um novo modelo de versionamento e entregas. A primeira entrega da versão nesse modelo foi desenvolvida em dois meses e as demais serão em 45 dias,  sendo elas menores se compararmos ao modelo atual.

Estas versões serão compostas por todas as melhorias planejadas nos ciclos de desenvolvimento desse período.

Dessa forma, não é necessário esperar mais de seis meses para ter acesso a uma grande versão. Participando desse modelo, você desfrutará das novas soluções em menor espaço de tempo, realizando atualizações mais rápidas e menos impactantes.  

Esta novidade tem como objetivo atendermos a um mercado que se mostra cada vez mais dinâmico e exigente. 




Veja como funcionará esse ciclo:

  • No primeiro mês teremos o desenvolvimento das soluções.

  • Já no segundo teremos um período de homologação dessas soluções, visando entregar a você um produto de alta qualidade.


A partir do momento que você optar por atualizar uma versão menor de uma rotina, 28.7 por exemplo, sempre que solicitar uma melhoria ou um ajuste receberá a última versão disponível desse produto, versão essa que poderá conter novo pacote de melhorias. Caso você queria se manter em uma versão fixa, sem receber atualizações, você deverá se manter na versão maior, como por exemplo 29.

Controle de Versão 

O controle de versões é realizado conforme o esquema: XX.T.YY.ZZZ, confira abaixo o significado de cada grupo:

  • (XX) Major Version
    Controla a Versão do WinThor: este grupo sofre incremento sempre que for planejado o lançamento de uma nova versão. O lançamento acontece geralmente a cada 12 meses e com entregas de modificações substanciais e significativas do sistema.
  • (T) Minor Version
    Controla os ciclos de evolução da versão corrente: este grupo sofre incremento sempre que for planejado novas funcionalidades da versão corrente. 
  • (YY) Release/Patch
    Controla as modificações ocorridas por melhorias ou correções que serão entregues aos clientes. 
    Quando for melhoria (no Branch 28M) este número será sempre ZERO. 
    Depois de liberar para o cliente (versão em manutenção: 27, 28, 28.1, etc) e haver necessidade de manutenção, deve ser incrementado apenas uma vez a cada instancia do processo, ou seja, a cada solicitação é incrementada apenas na primeira vez que é encaminhado para o teste, ou seja, se houver retorno do teste não se altera mais este grupo.
  • (ZZZ) Build
    Controle as compilações ocorridas em um ciclo de evolução (28.0.0, 28.1.0, etc). Este número deve ser incrementado sempre que for liberado qualquer artefato para o teste. Começa do 1 (um) sempre que a Release for incrementado. 



<script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
 ga('create', 'UA-91324488-2', 'auto', 'newTracker');
 ga('newTracker.send', 'pageview');
</script>
<script>
 ga('create', 'UA-91324488-2', 'auto', 'newTracker');
 ga('newTracker.send', 'pageview');
</script>