Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sistema de versões #3

Open
rlafuente opened this issue Mar 14, 2015 · 4 comments
Open

Sistema de versões #3

rlafuente opened this issue Mar 14, 2015 · 4 comments

Comments

@rlafuente
Copy link
Contributor

Para podermos assegurar alguma estabilidade na publicação das datapackages, faz sentido implementarmos um sistema de versionamento. Assim, alguém que construir uma app com um dataset não corre risco de ver os dados alterados subitamente quando a data package é atualizada.

Faz sentido incluir a data no número da versão para os casos de datasets em que os dados são atualizados regularmente (ex: 0.2-20150421)

@gsilvapt
Copy link

gsilvapt commented Jan 9, 2016

Controlo de versões ou apenas a informação da última atualização? Dado se tratarem de datasets, parece-me que a última actualização seja melhor.

@rlafuente
Copy link
Contributor Author

Neste momento já usamos a data da última atualização; o problema é como identificar cada versão.

Um exemplo:

  1. Fiz uma app que usa o dataset das datas das eleições
  2. O dataset é entretanto alterado de uma forma que pode afectar as aplicações existentes (ex. mudança de nomes de colunas)
  3. Quero assegurar que a minha app fica "ligada" à versão correta.

Talvez este use case seja pouco prático porque imagino que a maioria das pessoas faria o download do dataset para usar localmente; no entanto, se vamos promover a prática de hotlinking (ligar diretamente ao url da Central), temos de assegurar que não há surpresas...

Daí a ideia de numerar as versões, para também termos um bom registo das melhorias e alterações que foram feitas aos datasets. O senão é que isto implica algum trabalho e disciplina de documentação que, francamente, é uma seca.

@gsilvapt
Copy link

Um lançamento em profundidade: Porque não uma API em que isso ficaria escrito lá para os developers utilizarem consoante queiram? Nunca vi o processo de criação de uma API mas presumo que dê para acrescentar um campo que diga a última actualização e já é algo que os próprios developers podem utilizar nas suas apps, sites e quê mais para que seja mais fácil identificar o espaço temporal que estamos a lidar.

@rlafuente
Copy link
Contributor Author

O problema permanece sobre como catalogas cada versão publicada de um dataset.

A fonte canónica dos dados é a data package alojada num repositório Git. A Central de Dados descarrega o repositório e gera um site HTML. Podemos acrescentar uma API à Central (aliás, ela já tem uma mini-API linkada na home), mas isso não resolve o problema de haver uma numeração consistente de versões na data package.

Ou seja, não é algo que se resolva com software: a convenção de versões é uma decisão que é preciso tomar, desenvolver e documentar a norma a que chegarmos, e editar as data packages em conformidade :-)

Devia ter linkado no issue original a referência a versionamento semântico, que é mais ou menos o que precisamos aqui.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants