Detalhe, faltando talvez link para a versão 1.1.0, e "o que há de novo na 1.1.1" about scielo_publishing_schema

[gustavofonseca]

Oi Peter,

Não, não falta. O release v1.1.1 é um “remendo” que complementa a versão v1.1, e pretendemos manter a granularidade da documentação nos releases de calendário fixo (v1.1, v1.2, …). Vou melhorar o texto que explica o ciclo de vida das versões.

-Gustavo

On 04/12/2014, at 08:36, Peter [email protected] wrote:

No texto introdutório falta o link para a 1.1.0 e talvez complementar com as release notes da v1.1.1.
Sugere-se também adicionar exemplos de numeração de versão.

Novas versões (e.g. v1.1) serão disponibilizadas em um calendário fixo, [...]

Duas versões são suportadas simultaneamente, a mais recente (e.g. v1.1) e a imediatamente anterior (e.g. v1.0). [...].

—
Reply to this email directly or view it on GitHub #37.

[ppKrauss]

Hum... Mas aí entra em conflito com as considerações que fiz em seguida
sobre noção de Contrato.
Não é um documento de imprensa, nem um software, a norma SciELO tem valor
de Contrato, e como tal requer tags a cada modificação. Em legislação por
exemplo (ISO e RFC idem) até é preciso criar uma norma nova para dizer que
altera (uma virgula que seja) a anterior...

Entendo que subversões possam corrigir português, melhorar figuras,
exemplos e didática do texto.
Mas há que se distinguir "subversões com novas deliberações" de "subversões
com correções de texto".
As "novas deliberações" é que criam o problema que descrevo, de conflito
contratual: não se pode retroagir num contrato.

Em 4 de dezembro de 2014 10:46, Gustavo Fonseca [email protected]
escreveu:

Oi Peter,

Não, não falta. O release v1.1.1 é um “remendo” que complementa a versão
v1.1, e pretendemos manter a granularidade da documentação nos releases de
calendário fixo (v1.1, v1.2, …). Vou melhorar o texto que explica o ciclo
de vida das versões.

-Gustavo

On 04/12/2014, at 08:36, Peter [email protected] wrote:

No texto introdutório falta o link para a 1.1.0 e talvez complementar
com as release notes da v1.1.1.
Sugere-se também adicionar exemplos de numeração de versão.

Novas versões (e.g. v1.1) serão disponibilizadas em um calendário fixo,
[...]

Duas versões são suportadas simultaneamente, a mais recente (e.g. v1.1)
e a imediatamente anterior (e.g. v1.0). [...].

—
Reply to this email directly or view it on GitHub <
https://github.com/scieloorg/scielo_publishing_schema/issues/37>.

—
Reply to this email directly or view it on GitHub
#37 (comment)
.

[gustavofonseca]

Eu entendo as tuas considerações e visão do SciELO PS como algo que vai além de uma especificação adotada pelo SciELO para o recebimento de dados. Tratar o SciELO PS como um contrato, algo semelhante a um RFC, implica em uma carga de processos formais que atualmente não temos condições ou interesse de lidar. O SciELO PS atualmente está sendo gerido de maneira análoga a um software, e é o melhor que podemos fazer por hora.

On 04/12/2014, at 10:52, Peter [email protected] wrote:

Hum... Mas aí entra em conflito com as considerações que fiz em seguida
sobre noção de Contrato.
Não é um documento de imprensa, nem um software, a norma SciELO tem valor
de Contrato, e como tal requer tags a cada modificação. Em legislação por
exemplo (ISO e RFC idem) até é preciso criar uma norma nova para dizer que
altera (uma virgula que seja) a anterior...

Entendo que subversões possam corrigir português, melhorar figuras,
exemplos e didática do texto.
Mas há que se distinguir "subversões com novas deliberações" de "subversões
com correções de texto".
As "novas deliberações" é que criam o problema que descrevo, de conflito
contratual: não se pode retroagir num contrato.

Em 4 de dezembro de 2014 10:46, Gustavo Fonseca [email protected]
escreveu:

Oi Peter,

Não, não falta. O release v1.1.1 é um “remendo” que complementa a versão
v1.1, e pretendemos manter a granularidade da documentação nos releases de
calendário fixo (v1.1, v1.2, …). Vou melhorar o texto que explica o ciclo
de vida das versões.

-Gustavo

On 04/12/2014, at 08:36, Peter [email protected] wrote:

No texto introdutório falta o link para a 1.1.0 e talvez complementar
com as release notes da v1.1.1.
Sugere-se também adicionar exemplos de numeração de versão.

Novas versões (e.g. v1.1) serão disponibilizadas em um calendário fixo,
[...]

Duas versões são suportadas simultaneamente, a mais recente (e.g. v1.1)
e a imediatamente anterior (e.g. v1.0). [...].

—
Reply to this email directly or view it on GitHub <
https://github.com/scieloorg/scielo_publishing_schema/issues/37>.

—
Reply to this email directly or view it on GitHub
#37 (comment)
.

—
Reply to this email directly or view it on GitHub #37 (comment).

[ppKrauss]

Ok, entendo que é por aí: tocar o barco é mais importante do que congelar por minúncias... Mas tentei esclarecer melhor no #38. Entendo que

0. é fundamental distinguir "atualização de layout, exemplos, etc." (são análogos de bugs) de "atualização de regras" (são análogos de novas funções). As subversões podem evitar impacto nas regras.

1. o conceito de Contrato não pode nem deve jamais ser negado, existem contratos reais entre fornecedores e revistas, e entre fornecedores e SciELO.

2. não precisamos entender as colocações do #38 como "carga de processos formais", não se sugere mudar processo algum, apenas tomar mais cuidado, e ao invés de fazer "upgrade de regras" na versão corrente, fazer o upgrade na versão seguinte.