Estou revoltado, faz dias que procuro um texto descente sobre versionamento e não encontro, portanto segue uma copilação do que achei:
Um programa, assim como um produto que você compra no supermercado, um carro ou um tênis passam por um processo de desenvolvimento para chegar até você, pois de nada adianta comprar um carro não finalizado ou um tênis sem sola. Desta forma, é um termo usado na área de desenvolvimento chamado “Gerenciamento de releases” e é aí que se define em que pé o programa está.
Alfa
Para começar o ciclo temos a versão alfa. O nome alfa deriva de uma letra do alfabeto grego e naquele sistema numeral tem valor 1. Por isso que esta versão pode ser considerada a primeira fase de um software, ou seja, os primeiros passos.
Esta versão serve para que o software desenvolvido já possa ser patenteado, por exemplo, ou que suas intenções e funções sejam conhecidas. Porém, nem sempre é destinado aos usuários finais, mas sim para outros desenvolvedores ou parceiros do projeto, já que pode apresentar muitos erros (bugs).
Beta 
Desta forma, ela pode ser comparada com o nosso primeiro beijo, pois já estamos beijando pessoas, ou seja, já estamos interagindo, mas ainda não chegamos à perfeição. O Orkut e o Gmail são os eternos betas da Internet, pois desde que foram lançados em 2004 e 2005 (aproximadamente)e até hoje o nome beta está lá.
Closed Beta
Além da versão Beta, é possível que você se depare com variações dela, como no caso, a Closed Beta. Como o Beta quer dizer que é algo ainda não concluído, mas possível de usar antes de haver a liberação do programa ele é distribuído para um grupo seleto de pessoas. Estas pessoas geralmente são especialistas, formadores de opinião ou conhecidos, desta forma em primeiro lugar eles testam e emitem uma avaliação para somente depois a versão Beta ser liberada para o público.
O Orkut foi um caso de Closed Beta, já que para acessar o serviço você precisava receber um convite de alguém que já usava o site de relacionamentos.
Open Beta
Hoje em dia, para usar o orkut você só precisa fazer uma conta Google e começar a fazer amigos sem precisar de convite. Isso é um exemplo de versão Open Beta, pois ela continua Beta, mas qualquer pessoa pode ter acesso à ela.
Release Candidate – RC
Release em inglês significa liberar, tornar disponível e é por isso que há a versão Release Candidate, ou em tradução livre, candidato à liberação. A versão Release Candidate, ou RC, pode ser considerada como a mais próxima da final, pois apresenta todas as funções, interface e desempenho sem erros consideráveis. Ela é o genro ou nora que algumas mães gostariam de ter, não é perfeito, mas já é possível usá-lo sem maiores problemas.
Gold
A versão Gold nem precisa de muitas definições ou explicações, pois o próprio nome já diz tudo, afinal ouro é ouro e não se fala mais nisso. Esta versão é a definitiva, o The End dos programas, mas é mais voltada para jogos, pois se um programa chega até este patamar é porque já está pronto para entrar nas máquinas dos usuários e não causar erros.
Na verdade a nomeação de uma versão como Gold é mais uma denominação que define a que pé anda o desenvolvimento do produto. Quando uma versão é chamada de Gold é porque ela está pronta para ser comercializada, mas chamar um programa ou game de Gold fica a critério do desenvolvedor, já que a palavra pode soar melhor aos ouvidos dos usuários.
É claro que “nem tudo o que reluz é ouro”, desta forma em muitos casos versões Gold também apresentam erros (o que é muito comum se tratando de computadores). Porém, vamos entender que a versão Gold pode ser considerada a final, entretanto sempre há algo a melhorar. Mas ela, com certeza, é o genro ou nora que sua mãe pediu.
No campo das nomenclaturas, deve-se observar que elas servem para que antes de baixar ou usar o produto possamos saber a que pé está seu desenvolvimento. Agora vamos falar de números, pois você já deve ter percebido que eles são frequentes junto aos nomes dos programas.
Confusão matemática
Se você reparar, há vários números junto ao nome e versão e, assim como estas, eles não estão lá à toa. Para que você entenda mais facilmente acompanhe este quadro que foi baseado no da fundação Apache Software Foundation:
Geralmente os programas apresentam três números separados por pontos. O MSN é um exemplo, confira a figura:
De acordo com a tabela, o último número representa o número de correções de erros após o lançamento do aplicativo, neste caso 206. O número entre os pontos mostra as melhorias ou pontos em que o programa evoluiu, aqui 864. E o primeiro número quer dizer que 14 funções de grande importância foram incorporadas ao programa desde o seu lançamento.
Vale lembrar que não há um padrão, ou melhor, regra para a nomenclatura de releases, desta maneira é possível haver variações (isso pode explicar o zero entre os números). É claro que o MSN é um exemplo farto já que está quase na décima versão. No entanto não é comum encontrar programas com tantos releases, porém é sempre bom saber o que cada número significa, vai que você precisa de algumas combinações para fazer alguma aposta.
Fonte: http://www.baixaki.com.br/info/1698-o-que-sao-versoes-alfa-beta-rc-e-gold-.htm
Na memoria
As 3 primeiras letras representam o fabricante e o modelo da memoria.
Os 3 numeros logo a seguir mostra a velocidade da mesma
Após os numeros vem o tipo. podendo varia de D e D2 (DDR e DDR2)
depois vem algumas informações sobre a latencia e etc e depois da "/" (sem aspas) vem o tamanho dos modulos de memoria. por exemplo /256, /512, /1G e assim por diante.
13. Como funciona a numeração de versões no CVS?
O CVS faz a numeração automática de versões e isso é suficiente para muitos usuários. Entretanto, para alguns usos mais específicos é interessante ter um conhecimento e controle maiores sobre como funciona o CVS nesse sistema de numeração.
13.1. Revisões
Cada versão de um arquivo tem um único número de revisão. Números de revisão se parecem com 1.1, 1.2, 1.2.3.4, etc. Um número de revisão sempre possui um número par de inteiros decimais separados por pontos.
13.2. Versões, revisões e liberações
Um arquivo pode ter diversas versões, como descrito acima. De maneira semelhante, um software pode ter diferentes versões. Para um software é sempre dada uma versão do tipo 4.2.1.
No conceito do CVS, o primeiro tipo de versão é chamado revisão e o segundo de liberação, vindo, respectivamente, do inglês revision e release.
13.3. Designando revisões
O padrão do CVS é designar revisões mantendo constante o primeiro número e mudando apenas o segundo, portanto teríamos 1.1, 1.2 e assim sucessivamente.
Quando um novo arquivo é adicionado, o segundo número será sempre um e o primeiro será igual ao maior primeiro número presente neste diretório. Por exemplo, suponha que em um diretório existam arquivos nas revisões 1.15, 3.12 e 5.5. O próximo arquivo a ser adicionado terá a revisão 5.1.
Pense nas revisões como um controle interno do CVS e não como algo que deva ser atrelado ao documento ou software em desenvolvimento. Para fazer essa amarração pode-se usar o recurso de marcas presente no CVS.
Entretanto, se para você o número da revisão de um arquivo é importante, este pode ser ajustado com a opção -r no comando cvs commit. Para adicionar um arquivo como revisão 6.0 no diretório exemplificado acima, o comando dado seria cvs commit -r 6.0 arquivo. O número da revisão que está sendo enviada deve ser maior que os da já existentes no diretório e, ainda no exemplo acima, seria impossível, por exemplo, enviar um arquivo como pertencente à revisão 4.0.
Fonte: http://www.inf.ufrgs.br/procpar/disc/inf01008/trabalhos/sem01-1/t1/cvs/
O controle de versão permite armazenar, controlar e restaurar itens em uma lista e arquivos em uma biblioteca à medida que eles são alterados.
Neste artigo
Visão geral
Quando as versões são controladas para listas e bibliotecas, as revisões nos itens ou arquivos e suas propriedades são armazenadas. Isso permite gerenciar melhor o conteúdo à medida que ele é revisado e até restaurar a versão anterior — por exemplo, se for cometido um erro na versão atual. O controle de versão é especialmente útil quando várias pessoas trabalham juntas em projetos ou quando as informações passam por vários estágios de desenvolvimento e revisão.
O controle de versão fica disponível para itens de lista em todos os tipos de lista padrão — inclusive calendários, listas de acompanhamento de questões e listas personalizadas — e para todos os tipos de arquivo que podem ser armazenados em bibliotecas — inclusive Páginas de Web Parts.
É possível usar o controle de versão para fazer o seguinte:
- Registrar um histórico de versões Quando o controle de versão é ativado, é possível ver quando um item ou arquivo foi alterado e quem o alterou. Também é possível ver quando propriedades ou informações sobre o arquivo foram alteradas. Por exemplo, se alguém altera a data de conclusão de um item de lista, essas informações aparecem no histórico de versões. Nos arquivos, também é possível ver comentários que as pessoas incluem sobre suas alterações.
- Restaurar uma versão anterior como sua versão atual Você cometeu um erro em uma versão atual? Ou talvez seja preciso restaurar uma parte de um documento excluído. É possível substituir facilmente sua versão atual por uma versão anterior. Sua versão atual torna-se então parte do histórico de versões.
- Visualizar uma versão anterior É possível visualizar uma versão anterior — por exemplo, para consultar uma diretriz anterior — sem substituir sua versão atual. Em arquivos .aspx, é possível visualizar somente detalhes sobre as alterações feitas nos arquivos, e não as páginas reais que os arquivos criam.
As bibliotecas podem controlar tanto as versões principais, como aquelas às quais a nova seção foi adicionada e as versões secundárias, como aquelas nas quais um erro ortográfico foi corrigido. As listas podem controlar apenas versões principais. As listas e bibliotecas também podem limitar o número de versões que as pessoas podem armazenar.
Para habilitar o controle de versão, é preciso ter permissão para criar uma lista ou biblioteca.
Quando as versões são criadas
Quando o controle de versão é habilitado, as versões são criadas nas seguintes situações:
- Quando um item de lista ou arquivo for criado pela primeira vez ou quando um arquivo for carregado.
Observação Se for necessário o check-out do arquivo, primeiro deverá ser feito check-in do arquivo, para criar sua primeira versão.
- Quando um arquivo que tem o mesmo nome de um arquivo existente for carregado e a caixa de seleção Adicionar como uma nova versão a arquivos existentes estiver marcada.
- Quando as propriedades de um item de lista ou arquivo forem alteradas.
- Quando um arquivo for aberto, editado e salvo. Uma versão é criada quando você clica pela primeira vez em Salvar. Essa versão é atualizada com as alterações mais recentes que foram feitas no arquivo antes de fechá-lo.
Observação Uma versão não é criada toda vez que você ou outro usuário clica em Salvar, pois isso criaria várias versões.
- Quando é feito check-out de um arquivo, ele é alterado e é feito check-in novamente.
Observação Se você ou outro usuário descartarem a versão com check-out, nenhuma versão será criada.
É possível optar por excluir uma única versão de um arquivo —por exemplo, se você souber que cometeu um erro nessa versão — o que remove essa versão do histórico de versões. No entanto, se for excluído o arquivo real, todas as suas versões serão excluídas com ele. Por padrão, quando uma versão é excluída, ela é enviada para a Lixeira, onde pode ser recuperada até ser excluída permanentemente. No entanto, sua empresa manipula as exclusões de maneira diferente.
Importante Se sua empresa limitar o número de versões que armazena, as versões mais antigas serão excluídas permanentemente quando o limite for atingido. Elas não serão enviadas para a Lixeira.
Trabalhando com versões principais e secundárias
Dependendo das necessidades de sua empresa, a biblioteca pode ser configurada com o controle de versão simples, que controla apenas versões principais ou pode controlar tanto versões principais como secundárias. Se as pessoas de seu grupo não trabalham com freqüência em várias revisões, a empresa pode precisar apenas do controle de versão simples. Se várias pessoas trabalham juntas com arquivos e geralmente criam várias versões, a empresa pode controlar tanto as versões principais quanto as secundárias.
Fornecer dois tipos de versões pode ajudar sua equipe a gerenciar melhor seu conteúdo. As pessoas que trabalham com o conteúdo podem compreender melhor o status de um arquivo. Por exemplo, uma versão principal geralmente está pronta para um grupo maior ver e revisar, enquanto uma versão secundária é um rascunho no qual alguém ainda está trabalhando.
Controlar os dois tipos de versão também ajuda a tornar o histórico de versões mais significativo. Uma versão principal tem mais chances de representar uma etapa no desenvolvimento do arquivo, como quando um arquivo é enviado para revisão ou distribuído para outras pessoas. Uma versão secundária geralmente é usada para incrementar a rotina, como uma versão que é salva ou na qual é feito um check-in enquanto ainda está gravando o conteúdo ou uma versão na qual são corrigidos alguns pequenos erros. Quando for necessário visualizar o histórico de versões de um arquivo, as versões principais podem ajudar a identificar os estágios do desenvolvimento do arquivo e tornar o histórico mais fácil de navegar.
Quando as versões principais e secundárias são controladas, uma versão é armazenada por padrão como uma versão secundária, a menos que você designe a versão como uma versão principal. Quando você salva e fecha um arquivo, a versão é controlada como uma versão secundária. É preciso primeiro publicar o arquivo para que ele se torne uma versão principal. O arquivo pode ser publicado usando comandos suspensos em uma biblioteca. Em alguns programas compatíveis com o Microsoft Windows SharePoint Services, também podem ser usados comandos no programa. Por padrão, cada versão principal pode ter até 511 rascunhos (versões secundárias), mas o administrador ou proprietário do site pode limitar ainda mais o número de versões.
Com uma permissão para excluir versões, é possível substituir uma versão secundária por outra versão secundária. Por exemplo, é possível substituir uma versão se a versão anterior contiver um erro e não for necessário mantê-lo. Se uma versão principal for publicada e depois você perceber que cometeu um erro, será possível transformar a versão em uma versão secundária de novo ao cancelar sua publicação.
Se for feito check-out dos arquivos antes de trabalhar com eles, será possível designar de qual tipo de versão está fazendo check-in. Não será necessário publicar um arquivo se ele for designado como uma versão principal ao fazer check-in.
Numeração de versões
As versões são numeradas à medida que são criadas. Em uma lista ou biblioteca com o controle de versão simples habilitado, a versão 1 é a primeira versão criada ou carregada, e o número da versão aumenta por acréscimos de números inteiros, como na versão 2, versão 3 e assim por diante.
Quando as versões principais e secundárias são controladas, as versões principais são números inteiros e as versões secundárias são decimais. Por exemplo, 0.1 é a primeira versão secundária de um arquivo, 1.3 é a terceira versão secundária de um arquivo que foi publicado uma vez e 2.0 é a segunda versão principal de um arquivo publicado.
Em uma lista ou biblioteca, é possível exibir uma coluna Versão que exibe o número da versão de arquivos ou itens de lista, o que pode ser útil se sua equipe revisar com freqüência as informações. Localize links para obter mais informações sobre como trabalhar com modos de exibição na seção Consulte também.
Como o controle de versão funciona com a aprovação de conteúdo
O controle de versão principal e secundário se integra com a aprovação de conteúdo para listas e bibliotecas.
Quando a aprovação de conteúdo é obrigatória, um item de lista ou arquivo permanece em rascunho ou em estado pendente até ser aprovado ou rejeitado por alguém que possua permissão para aprová-lo. Se o item ou arquivo for aprovado, será atribuído a ele um status Aprovado na lista ou biblioteca e ele será exibido para qualquer pessoa com permissão para visualizar a lista ou biblioteca. Se for rejeitado, o item ou arquivo permanecerá em estado pendente e só ficará visível para pessoas com permissão para exibir rascunhos.
Quando é habilitado o controle de versão principal e secundário em uma biblioteca que exige aprovação de conteúdo, também é possível adicionar um fluxo de trabalho, se você ou alguém de sua empresa tiver criado um. Um fluxo de trabalho controla o modo como os arquivos se movem pelos processos de negócios, como revisão ou aprovação. É possível usar um fluxo de trabalho para gerenciar o processo de aprovação quando é feito check-in de versões principais.
Por padrão, em uma biblioteca que controla tanto versões principais como secundárias, primeiro é preciso publicar uma versão principal do arquivo antes que ela possa ser aprovada. As versões secundárias são consideradas rascunhos que ainda estão sendo desenvolvidos para que não apareçam como itens pendentes que estão aguardando aprovação.
Por exemplo, uma agência de viagens pode usar uma biblioteca de documentos para gerenciar arquivos. Ao mesmo tempo em que os membros da equipe desenvolvem uma nova proposta de vendas, eles controlam as versões secundárias do arquivo. Se cometerem algum erro em uma versão, será possível restaurar uma versão anterior. Ao concluir a proposta, será possível criar uma versão principal e, em seguida, publicá-la para aprovação de seu departamento jurídico e de seu gerente. Quando o arquivo for aprovado, outros funcionários da empresa poderão visualizá-lo.
Por padrão, um item ou arquivo pendente fica visível apenas para seu criador e para pessoas com permissão para aprovar itens, mas é possível especificar se outros grupos de usuários poderão visualizar o item ou arquivo.
Quando a aprovação de conteúdo for obrigatória, as pessoas que possuem permissão para ler o conteúdo mas que não possuem permissão para ver itens de rascunho verão a última versão aprovada ou a versão principal do item de lista ou arquivo. Se as versões principais e secundárias forem controladas em uma biblioteca e ninguém tiver publicado uma versão principal ainda, o arquivo não ficará visível para as pessoas que não possuem permissão para ver itens de rascunho.
Como o controle de versão funciona com o check-out de arquivo
Fazer ckeck-out de arquivos tira o melhor proveito do controle de versão. Quando for feito check-out de um arquivo, uma versão será criada apenas quando você fizer check-in do arquivo novamente para que seja possível designar especificamente quando uma versão for criada. Quando o check-out não for obrigatório, uma versão será criada quando você salvar um arquivo pela primeira vez e, em seguida, essa versão será atualizada quando ele for fechado. Se você abrir e salvar o arquivo novamente, outra versão será criada. Dependendo da situação, pode não haver necessidade de que várias versões sejam criadas, por exemplo, se tiver que ser fechado um arquivo para participar de uma reunião antes de terminar de fazer alterações no arquivo.
Quando o check-out for obrigatório, não é recomendável adicionar ou alterar um arquivo ou alterar as propriedades do arquivo sem antes fazer check-out. Quando check-in do arquivo é feito, surge uma solicitação para sejam fornecidos comentários sobre as alterações feitas, o que ajuda a criar um histórico de versões mais significativo.
Fonte: http://office.microsoft.com/pt-br/help/HA100215761046.aspx
Nenhum comentário:
Postar um comentário